Re: PG Killed by OOM Condition - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: PG Killed by OOM Condition
Date
Msg-id 20051003220742.GA10590@mark.mielke.cc
Whole thread Raw
In response to Re: PG Killed by OOM Condition  (Jeff Davis <jdavis-pgsql@empires.org>)
Responses Re: PG Killed by OOM Condition  (Jeff Davis <jdavis-pgsql@empires.org>)
List pgsql-hackers
On Mon, Oct 03, 2005 at 01:25:00PM -0700, Jeff Davis wrote:
> It's happened to me...
> Usually it's when there's some other runaway process, and the kernel
> decides to kill PostgreSQL because it can't tell the difference.
> I really don't like that "feature" in linux. Nobody has been able to
> explain to me why linux is the only OS with an OOM Killer. If someone
> here has more information, I'd like to know.
> When using linux I always set vm_overcommit=2.

I don't think it's the only one. Perhaps the only one with a default
setting of on?

I believe Solaris can be configured to over-commit memory.

The problem really comes down to the definition of fork(). UNIX fork()
requires that the system splits a process into two separate copies.
For an application that is currently using 500 Mbytes of virtual
memory, this would require that the system accept that each process,
may use its own complete copy of this 500 Mbytes, for a total of 1
Gbyte in active use. fork() a few more times, and we hit 2 Gbytes, 4
Gbytes - whatever. Even if only for an instant, and even if the pages
are copy-on-write, the system has to consider the possibility that
each application may choose to modify all pages, resulting in complete
copies.

Solaris defaults to not over committing. This means that such an
application, as defined above, would fail at one of the invocations
of fork(). Even though the memory isn't being used - Solaris, by default,
isn't willing to 'over commit' to having the memory allocated as a result
of fork(). Some very large applications don't work under Solaris as a
result, unless this setting is disabled.

Linux takes the opposite extreme. It assumes that copy-on-write will
get us through. The fork() would be allowed - but if available virtual
memory actually does become low, it's faced with a hard decision. It
either fails an application of its choice in a controlled "OOM"
manner, by trying to guess which application is misbehaving, and
deciding to kill that one - or it waits until memory really is gone,
at which point MANY applications may start to fail, as their page
fault fails to allocate a page, and the process dies a horrible death.

It's not an easy decision. Linux isn't wrong. Solaris isn't wrong.
Most people never hit these problems, and the people that do, are
just as likely to hit one problem, or the other. The grass is always
greener on the side of the fence that isn't hurting me right now,
and all that.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [PERFORM] A Better External Sort?
Next
From: "Jim C. Nasby"
Date:
Subject: COPY FROM with CSV header