[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT (slightly) swap limits

Ron Johnson wrote:
Hash: SHA1

On 04/27/08 00:55, Marc Shapiro wrote:
Ron Johnson wrote:
Hash: SHA1

On 04/26/08 18:13, Bob Proulx wrote:
I learned about this because I didn't know it when I set up a computer
server pool to be used for some large memory consuming simulations.
They all had 16G of RAM with 64-bit process space.  I knew that if
they started swapping that they would run to slowly for us and the
plan was to avoid swapping.  If they don't swap they don't need swap
space and so I didn't configure any on them.  I came from a Unix
background and didn't expect this different behavior when running on
Linux.  We started to see processes randomly stop running.  Nothing
was ever logged from the log files for those processes.  Large memory
applications never recorded being out of memory.  They just stopped
running.  A number of folks started cursing Linux for being unreliable
and at that moment for us it was very unreliable!  It was from that
experience I learned about the Linux memory overcommit and oom killer
behavior.  And with that knowledge I knew that I needed to rebuild the
computer server pool with overcommit off and enough VM.


This was a very interesting post.  Just now I modified sysconf and
boosted swap up to 2x RAM.
I had skipped Bob's post and had to go back in the archives to read it. I'm glad that I did. Could this be the reason that Firefox sometimes
just disappears?  No warning.  No noticeable problems, just, suddenly,
no Firefox.

Happens to me too, but the system never grinds to a swap-thrashing
crawl beforehand, so I don't think OOM is the cause.

What I think the cause is, on x86-32 systems, at least, is that the
process runs out of it's 2GB "process space".  This won't happen on
a 64-bit system.  What you'll see there is what you'd traditionally
expect from a process that just grows and grows and grows: swap-
thrashing craw, and then finally the OOM Killer kills it, or a
malloc() fails and FF does whatever it's supposed to do when a
malloc() fails.

             I can't, offhand, remember it happening with other
programs, but it might have, so it might just be a Firefox thing, but
Bob's post got me wondering.  Can I avoid this vanishing trick of
Firefox by increasing swap and turning off overcommit?  If so, it would
be a good thing.

I don't think so.  FF3 should severely diminish this problem, though.
Still waiting for it to get out of beta.

Marc Shapiro

Reply to: