Yan Li wrote:
> On 12/19/18 5:05 AM, Jerry Geis wrote:
>
>> I have three machines running CentOS 7.6 in desktop mode. 2 are fine.
>> 1 of them is having a memory issue that is Out of memory
>> [17878] 1000 17878 206999142311 118988800 0
>> gnome-shell
>>
>> This
On 12/19/18 5:05 AM, Jerry Geis wrote:
I have three machines running CentOS 7.6 in desktop mode. 2 are fine.
1 of them is having a memory issue that is Out of memory
[17878] 1000 17878 206999142311 118988800 0
gnome-shell
This gnome-shell looking at /var/log/messages
Hi,
I have three machines running CentOS 7.6 in desktop mode. 2 are fine.
1 of them is having a memory issue that is Out of memory
[17878] 1000 17878 206999142311 118988800 0
gnome-shell
This gnome-shell looking at /var/log/messages after reboot - is the HIGHEST
amount
Jerry Geis wrote on Wed, 29 Jul 2009 18:30:05 -0400:
Any thoughts?
Doesn't top help in finding out what's eating your RAM?
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
___
CentOS
On Thu, 2009-07-30 at 10:31 +0200, Kai Schaetzl wrote:
Jerry Geis wrote on Wed, 29 Jul 2009 18:30:05 -0400:
Any thoughts?
Doesn't top help in finding out what's eating your RAM?
Sometimes, use of the SAR system is better.
Kai
--
Bill
On Wed, Jul 29, 2009 at 4:30 PM, Jerry Geisge...@pagestation.com wrote:
I am getting this message quite often lately.
Centos 5.3, AMD dual core 5050e system x64
1 GIG ram, 4 GIG swap
Well that is a lot of swap for a server.. if something really starts
using that much swap its going to most
On Wed, 2008-07-30 at 19:55 -0700, Craig White wrote:
snip
I suppose I could run some type of cron script that does something
like...
top -n 1 -b /tmp/top.log
so if it happens again, I get a memory snapshot history...is there a
better idea?
If you have the sar packages installed the
On Wed, 2008-07-30 at 19:55 -0700, Craig White wrote:
snip
P.S. And running sar. Use a short sample interval is you suspect a
rapidly inflating hog. If the hog is only slowly bloating, a slow
sample rate will do.
If it's a memory leak, I can't recall (been years... no, decades since
I dinked
On Thu, 2008-07-31 at 06:47 -0400, William L. Maltby wrote:
On Wed, 2008-07-30 at 19:55 -0700, Craig White wrote:
snip
I suppose I could run some type of cron script that does something
like...
top -n 1 -b /tmp/top.log
so if it happens again, I get a memory snapshot
On Thu, 2008-07-31 at 10:16 -0700, Craig White wrote:
snip
but on July 27 - the day I updated - no users in office - same time
period, the kbswpfree starting swinging wildly.
But sar doesn't tell me which program is leaking memory but perhaps it
was just the update without reboot that was
On Thu, 2008-07-31 at 17:18 -0400, William L. Maltby wrote:
On Thu, 2008-07-31 at 10:16 -0700, Craig White wrote:
snip
but on July 27 - the day I updated - no users in office - same time
period, the kbswpfree starting swinging wildly.
But sar doesn't tell me which program is leaking
Craig White wrote:
Yeah, I have some users who despite my occasional begging to get them to
shut down or at least log off, simply don't.
While it can be done with grep I like the slay command, I don't think
it's available in RHEL
NAME
slay - kill all processes belonging to a user
On Thu, 31 Jul 2008 15:08:16 -0700 (PDT)
nate [EMAIL PROTECTED] wrote:
While it can be done with grep I like the slay command, I don't think
it's available in RHEL
pkill
--
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com
___
On Thu, 31 Jul 2008, nate wrote:
Craig White wrote:
Yeah, I have some users who despite my occasional begging to get
them to shut down or at least log off, simply don't.
While it can be done with grep I like the slay command, I don't
think it's available in RHEL
NAME
slay - kill
On Thu, Jul 31, 2008 at 2:59 PM, Craig White [EMAIL PROTECTED] wrote:
nothing like a system death and cold reboot to make certain that all
users are logged out I guess ;-)
Yeah, I have some users who despite my occasional begging to get them to
shut down or at least log off, simply don't.
just had a server hang on me...seems pretty clearly that some process
stole all the RAM (clamd?)
Jul 30 16:26:04 srv1 kernel: auditd invoked oom-killer:
gfp_mask=0x201d2, order=0, oomkilladj=-17
Jul 30 16:26:08 srv1 kernel: [c0457d36] out_of_memory+0x72/0x1a4
Jul 30 16:26:08 srv1 kernel:
On Wed, Jul 30, 2008 at 20:31, Craig White [EMAIL PROTECTED] wrote:
how does one determine who the culprit was?
Very hard... the kernel tries to guess which process is causing the
issue, but from what I've seen (and I see OOMs every week) it guesses
wrong most of the time. In my case, the victim
On Wed, 2008-07-30 at 22:19 -0400, Filipe Brandenburger wrote:
On Wed, Jul 30, 2008 at 20:31, Craig White [EMAIL PROTECTED] wrote:
how does one determine who the culprit was?
Very hard... the kernel tries to guess which process is causing the
issue, but from what I've seen (and I see OOMs
18 matches
Mail list logo
