On Fri 25 Sep 2020 at 07:41:10 (-0600), Charles Curley wrote:
> On Thu, 24 Sep 2020 23:37:52 + Pariksheet Nanda
> wrote:
>
> > I don't know how to empirically test that swap works
>
> Try free. E.g.:
>
> root@jhegaala:~# free
> totalusedfree shared buff/
>> The hanging behavior is like a step function: the computer goes from being
>> fully responsive to completely unresponsive;
>
> That's very much unlike a normal "out of RAM" situation, OTOH.
> Normally what happens is that the OS starts to shuffle things around
> (throwing out cached data, moving
Hi Linux-Fan,
>>> I just checked my other server which has ZFS on root without encryption,
>>> and see that I did not enable swap at all on that machine. So I'll disable
>>> swap, thrash the RAM with `stress`, and then hopefully the OOM-killer works
>>>
On Fri 25 Sep 2020 at 07:41:10 -0600, Charles Curley wrote:
> On Thu, 24 Sep 2020 23:37:52 +
> Pariksheet Nanda wrote:
>
> > I don't know how to empirically test that swap works
>
> Try free. E.g.:
>
> root@jhegaala:~# free
> totalusedfree shared buff/ca
On Fri, 2020-09-25 at 07:41 -0600, Charles Curley wrote:
> On Thu, 24 Sep 2020 23:37:52 +
> Pariksheet Nanda wrote:
>
> > I don't know how to empirically test that swap works
>
> Try free. E.g.:
>
> root@jhegaala:~# free
> totalusedfree shared buff/cache
On Thu, 24 Sep 2020 23:37:52 +
Pariksheet Nanda wrote:
> I don't know how to empirically test that swap works
Try free. E.g.:
root@jhegaala:~# free
totalusedfree shared buff/cache available
Mem: 78605095 780 597
> I neglected to mention that I run XFCE with its System Load Monitor panel
> plugin having a RAM indicator bar that climbs and maxes out right before the
> hang. RAM is something I often need to monitor because I run scientific
> computing programs which can also exhaust my RAM if I'm not careful
Pariksheet Nanda writes:
> I just checked my other server which has ZFS on root without encryption,
and see that I did not enable swap at all on that machine. So I'll disable
swap, thrash the RAM with`stress`, and then hopefully the OOM-killer works
like it does on that machine.
Yay!
> I just checked my other server which has ZFS on root without encryption, and
> see that I did not enable swap at all on that machine. So I'll disable swap,
> thrash the RAM with`stress`, and then hopefully the OOM-killer works like it
> does on that machine.
Yay! Inde
Hi Stefan,
>> My crystal ball says that you're not running out of RAM, but you're
>> hitting a nasty bug instead. I hope I'm wrong.
>
> Perhaps there's a ZFS bug or misconfiguration that happens before the
> OOM-killer has the chance to be involked. The
see what they
say. Maybe something is misconfigured with using the ZFS swap partition and
there might be some ZFS related logging I could collect to better understand
what's going on.
Perhaps there's a ZFS bug or misconfiguration that happens before the
OOM-killer has the chance to be involked. The encryption support is a
relatively new feature and I wonder how it behaves with swap.
Thank you for all your thoughtful questions and insights!
> Stefan
Pariksheet
Hi,
> Every few days, my desktop runs out of RAM, and this usually happens while
> web browsing.
What exactly makes you think the problem is that it ran out of RAM?
> I wait for as much as an hour and a half, but just see the
> screen as frozen the way it was at the time of the hang. 8 GB RAM is
using the default 0 setting. I can reproduce the problem using:
stress -m 4 --vm-bytes 1000M
My persistent journald logging shows me no evidence of memory pressure being
registered by the kernel or the oom-killer being involved leading up to the
hang, so I'm not sure what to do next.
Pariksheet
tim truman wrote:
> Please help me understand why oom-killer was invoked?
You already know that the reason is that your system was out of
memory. Why even ask.
The OOM killer is a terrible thing. I have ranted about it often.
Turning it off is the best way to avoid it.
I have previou
Stan Hoeppner wrote:
On 3/19/2012 3:48 AM, tim truman wrote:
Please help me understand why oom-killer was invoked?
You already know the answer: what does "oom" stand for?
>From the SAR logs we can see that there is lots of memory in use by the
system cache, but free is low
On 3/19/2012 3:48 AM, tim truman wrote:
> Please help me understand why oom-killer was invoked?
You already know the answer: what does "oom" stand for?
>>From the SAR logs we can see that there is lots of memory in use by the
> system cache, but free is low. How can w
Hi,
Please help me understand why oom-killer was invoked?
>From the SAR logs we can see that there is lots of memory in use by the
system cache, but free is low. How can we ensure there is more memory
available in free to avoid triggering oom-killer?
>From Kernel Log:
Mar 16 23:30:06
[...]
My guess is that sshd tries to protect itself against the OOM-killer so
that you can still log in to a system that has gone OOM. If there is no
network available, it doesn't do this because you cannot log in remotely
anyway.
The bug seems to be that sshd does not reset the OOM adjus
twork interface. I then tried
binding /etc/ssh/sshd_config to only listen on 127.0.0.1.. effectively
bypassing the eth0 interface, whilst still allowing it to be loaded.
But the problem still happens.
[...]
My guess is that sshd tries to protect itself against the OOM-killer so
that you can st
erface. I then tried
> binding /etc/ssh/sshd_config to only listen on 127.0.0.1.. effectively
> bypassing the eth0 interface, whilst still allowing it to be loaded.
> But the problem still happens.
[...]
My guess is that sshd tries to protect itself against the OOM-killer so
that you can
er instances on the working server, are not :S
Any input from anyone on the below would be VERY much appreciated.
Cal
Original Message
Subject: Re: Fwd: cgroup OOM killer loop causes system to lockup
(possible fix included)
Date: Sun, 29 May 2011 23:24:07 +0100
From: Cal
are set to -17,
yet the sshd user instances on the working server, are not :S
Any input from anyone on the below would be VERY much appreciated.
Cal
Original Message
Subject: Re: Fwd: cgroup OOM killer loop causes system to lockup
(possible fix included)
Date: Sun, 2
gain it crashed!
what can I do?
uninstall and reinstall apache?
please help me.
regards,
Guillermo.
>
>
> Apr 15 06:18:22 linux kernel: oom-killer: gfp_mask=0x1d2
> Apr 15 06:18:23 linux kernel: DMA per-cpu:
> Apr 15 06:18:23 linux kernel: cpu 0 hot: low 2, high 6, batch 1
>
ht it
could be a DOS attact, so I configured my firewall for not accepting
the tcp:80 connections, and restart system, once again it crashed!
what can I do?
uninstall and reinstall apache?
please help me.
regards,
Guillermo.
Apr 15 06:18:22 linux kernel: oom-killer: gfp_mask=0x1d2
Apr 15 06:
ernel: oom-killer: gfp_mask=0x1d2
Apr 15 06:18:23 linux kernel: DMA per-cpu:
Apr 15 06:18:23 linux kernel: cpu 0 hot: low 2, high 6, batch 1
Apr 15 06:18:23 linux kernel: cpu 0 cold: low 0, high 2, batch 1
Apr 15 06:18:23 linux kernel: Normal per-cpu:
Apr 15 06:18:23 linux kernel: cpu 0 hot: low 30,
On Sun, 27 Nov 2005 13:31:26 + (GMT)
Thomas Adam <[EMAIL PROTECTED]> wrote:
> > I am no script whiz and all I was trying to do is figure the HD size,
> That's why there's the 'du' command.
The 'df' command too, if you want to see the size of the disk.
HTH, -ol
--
I will live forever, or die
mmand.
> Has anybody seen an explanation of the oom-killer parameters for the
> quick-start witted? It would be nice if you got some sort of prior
> warning. But maybe that script tried to allocate everything. In this
> case though it would have been better just to kill bash.
It happe
Hi Debian,
For the first time in my (long) life oom-killer got going.
I was running 2.6.14-ck5, from here:
http://members.optusnet.com.au/ckolivas/kernel/
and it happened when I executed this *wrong* script:
echo `expr $(*blockdev --getsize* $DEVICE) \* $(blockdev --getss $DEVICE)`
I am no
get stuck
> for a while as a result of the big file.
If it is swapping? Depending on the kernel and swap device, yes, the
machine will slow down to a crawl.
> In other words would the symptoms of an oom-killer event and the
> resource shortage before it be noticable for a longer period? Or
&
e file on exit (or pressing
$), that is a lot of IO to do. On linux 2.4 at least if one process is
using a lot of IO, the other processes seem to grind to a halt. I think
they are fixing this in 2.6. Perhaps you could try upgrading to 2.6 if
you're using 2.4?
> In other words would the s
nd 1 GB swap. Is there a limit to how
much swap I can/should add to the system?
The points concerning the mbox file are taken (in fact I knew as
much). Do you think that Linux might stop to respond or get stuck
for a while as a result of the big file.
In other words would the symptoms of an oom-k
er gigabyte
> of
> swap (as root):
This is a *very* good idea on any machine where you ever got the oom killer
to show up. Add another gigabyte of swap immediately, then try to track
down whatever is chewing up memory.
> If this helps, you can use parted or whatever to resize your parti
On Sat, Dec 18, 2004 at 10:37:22AM +0100, Robert Ian Smit wrote:
> Are those oom problems related to hardware, kernel or userland
> software?
userland software eating all the virtual memory
> The system is mainly used as a dropbox for a huge amount of mail.
> Mutt is opening and working on a 1.5
of the incidents a local user was still able to
visit webpages (not 100% sure that the pages were not taken from the
browser cache).
However in the log files I find entries concerning oom-killer
events which I never saw before. My understanding of memory
management and kernel technicalities is not
34 matches
Mail list logo
