Ron Johnson wrote: > Marc Shapiro wrote: > > 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.
If a system doesn't have any swap space enabled, or just too little, then it can't ever slow down due to swapping when the system is in a memory deficient condition. In that case it will move immediately to the OOM killer. If the OOM killer is invoked then the syslog should have some mention of "oom" with information (at least a process id) of what action was taken. If you never see "oom" then you are not tripping into the out of memory killer. (I am pretty sure that "oom" is the message logged. It has been a while since I have seen it. :-) Hopefully you never see an oom killer message logged. In the normal case everything "just works" and it isn't a problem. It really only comes into play when running more applications than the system can handle regarding memory. I think your Firefox is probably crashing itself due to other problems. For me it is a pig but not usually enough to run out of memory. I also think some of the FF plugins may be suspect. Check your syslog and hopefully you don't see any oom killer messages. In which case this is not the explanation for your Firefox crashes. > What I think the cause is, on x86-32 systems, at least, is that the > process runs out of it's 2GB "process space". You actually meant 3G memory limit. A 32-bit process running on the Linux kernel can address up to 3G of memory. > 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. Just a clarification. When overcommit is enabled then malloc() and fork() won't ever return a failure even on 64-bit systems. Using a 64-bit system makes it less likely to hit address space limitations because the address space limit is so very much bigger but doesn't change the semantics of memory overcommit. As you say, systems with enough virtual memory in the form of swap space trying to run large memory applications may find the system thrashing and that would slow the system down. Slow system behavior is definitely a symptom of thrashing. You can look at your swap paging rates with many tools. I like using 'vmstat' (CLI) or 'xosview' (GUI). Look at the si/so (swapin/swapout) numbers. Of course zero pages swapping is good but a low number isn't necessarily bad. Pushing infrequently used data to disk can free up memory for better use which is actually a good thing. High swap page rates indicate swapping and perhaps indicate thrashing. > > 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. Agreed. Bob
signature.asc
Description: Digital signature
