Re: OT (slightly) swap limits
-----BEGIN PGP SIGNED MESSAGE-----
On 04/27/08 00:55, Marc Shapiro wrote:
> Ron Johnson wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
> 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!!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----