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

Re: OT (slightly) swap limits



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

Attachment: signature.asc
Description: Digital signature


Reply to: