-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: >> [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!! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIFBldS9HxQb37XmcRAqGoAJ9r4AlI0OcphWESvRHTlutFIo6ELwCgn8si uP5ZYWa2t3xItTyw4VPA1RE= =xvl6 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
