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

Re: OT (slightly) swap limits

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:
>> [snip]
>>> 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.
>> [snip]
>> 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.

- --
Ron Johnson, Jr.
Jefferson LA  USA

We want... a Shrubbery!!
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: