Re: PG Killed by OOM Condition

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
Cc: mark(at)mark(dot)mielke(dot)cc, John Hansen <john(at)geeknet(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG Killed by OOM Condition
Date: 2005-10-04 09:45:53
Message-ID: 20051004094547.GA17589@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 03, 2005 at 11:47:57PM -0700, Jeff Davis wrote:
> I think that I've run into the OOM killer without a fork() being
> involved, but I could be wrong. Is it possible to be hit by the OOM
> killer if no applications use fork()?

fork() is the obvious overcomitter. If Netscape wants to spawn a new
process, it first has to fork 50MB of memory, then free probably most
of it because it execs some little plugin. If processes mmap() a large block
and then doesn't use it until later. Similar idea with brk(). If you
run out of swap at the wrong moment... Recent versions are more clever
about who to kill. Sometimes you just get unlucky...

It's always killed the right process for me (Mozilla derivative leaked
masses of memory over long period).
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-10-04 09:51:22 Re: Vacuum and Transactions
Previous Message Simon Riggs 2005-10-04 09:16:40 Re: Tuning current tuplesort external sort code for 8.2