The out-of-memory killer.

Bill · External Since: Aug 01, 2007 Posts: 2

What can a process do to insure that it is the process which dies
when the system runs out of memory. (This is as opposed to invoking
the out-of-memory kill and sacrificing some other program.)

I am interested in suggestions which involve changing the processes
environment rather than editing the applications source code and
making
changes there.

Thanks.

Bill

The Ghost In The Machine · External Since: Aug 04, 2005 Posts: 3878

In comp.os.linux.setup, Bill
<galaxyblue63.DeleteThis@gmail.com>
wrote
on Wed, 01 Aug 2007 10:31:52 -0700
<1185989512.821338.45970.DeleteThis@i38g2000prf.googlegroups.com>:
> What can a process do to insure that it is the process which dies
> when the system runs out of memory. (This is as opposed to invoking
> the out-of-memory kill and sacrificing some other program.)
>
> I am interested in suggestions which involve changing the processes
> environment rather than editing the applications source code and
> making
> changes there.
>
> Thanks.
>
> Bill
>

The concept you're apparently looking for appears to be
called "overcommit", and apparently can be adjusted
by the command

sysctl -w vm.overcommit_memory=mode

where mode is one of the following:

0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slighly more memory in this mode. This is the
default.

1 - No overcommit handling. Appropriate for some scientific
applications.

2 - (NEW) strict overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
Depending on the percentage you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.

http://archives.postgresql.org/pgsql-patches/2003-11/msg00194.php
http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html

There is a patch if one needs a per-user overcommit policy
(the default affects the entire system):

http://lwn.net/Articles/233317/

I disclaim any knowledge of the details, of course, but it
might be worth looking at. Wink

--
#191, ewill3.DeleteThis@earthlink.net
Linux. Because life's too short for a buggy OS.

--
Posted via a free Usenet account from http://www.teranews.com

Jean-David Beyer · External Since: Jul 02, 2006 Posts: 444

Bill wrote:
> What can a process do to insure that it is the process which dies when
> the system runs out of memory. (This is as opposed to invoking the
> out-of-memory kill and sacrificing some other program.)
>
> I am interested in suggestions which involve changing the processes
> environment rather than editing the applications source code and making
> changes there.
>
As long as you have enough memory and swap space, you should not run out of
memory in the first place. Why not cure the problem instead of finding a way
around it? Either get more memory, or allocate enough swap space. These
days, getting more RAM is probably the way to go because if you end up using
a lot of swap space, your performance will likely take a huge hit.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:45:01 up 9 days, 7:29, 2 users, load average: 4.36, 4.51, 4.40

zeno · External Since: Jun 08, 2007 Posts: 18

On Aug 1, 1:31 pm, Bill <galaxyblu....TakeThisOut@gmail.com> wrote:
> What can a process do to insure that it is the process which dies
> when the system runs out of memory. (This is as opposed to invoking
> the out-of-memory kill and sacrificing some other program.)
>
> I am interested in suggestions which involve changing the processes
> environment rather than editing the applications source code and
> making
> changes there.
>
> Thanks.
>
> Bill

As my own memory is a bit faulty, and I want to send this off to you,
I can say that in the TOP program ('top') you can adjust many of the
parameters. Read 'man TOP' or look in a Linux Nutshell reference.
Also look at your PS tool 'ps al' (no flag)

Bill · External Since: Aug 01, 2007 Posts: 2

On Aug 1, 3:57 pm, The Ghost In The Machine
<ew....DeleteThis@sirius.tg00suus7038.net> wrote:
> In comp.os.linux.setup, Bill
> <galaxyblu....DeleteThis@gmail.com>
> wrote
> on Wed, 01 Aug 2007 10:31:52 -0700
> <1185989512.821338.45....DeleteThis@i38g2000prf.googlegroups.com>:
>
> > What can a process do to insure that it is the process which dies
> > when the system runsout of memory. (This is as opposed to invoking
> > theout-of-memorykill and sacrificing some other program.)
>
> > I am interested in suggestions which involve changing the processes
> > environment rather than editing the applications source code and
> > making
> > changes there.
>
> > Thanks.
>
> > Bill
>
> The concept you're apparently looking for appears to be
> called "overcommit", and apparently can be adjusted
> by the command
>
> sysctl -w vm.overcommit_memory=mode
>
> where mode is one of the following:
>
> 0 - Heuristic overcommit handling. Obvious overcommits of
> address space are refused. Used for a typical system. It
> ensures a seriously wild allocation fails while allowing
> overcommit to reduce swap usage. root is allowed to
> allocate slighly more memory in this mode. This is the
> default.
>
> 1 - No overcommit handling. Appropriate for some scientific
> applications.
>
> 2 - (NEW) strict overcommit. The total address space commit
> for the system is not permitted to exceed swap + a
> configurable percentage (default is 50) of physical RAM.
> Depending on the percentage you use, in most situations
> this means a process will not be killed while accessing
> pages but will receive errors on memory allocation as
> appropriate.
>
> http://archives.postgresql.org/pgsql-patches/2003-11/msg00194.phphttp:...ww.netw
>
> There is a patch if one needs a per-user overcommit policy
> (the default affects the entire system):
>
> http://lwn.net/Articles/233317/
>
> I disclaim any knowledge of the details, of course, but it
> might be worth looking at. Wink

>
> --
> #191, ewi....DeleteThis@earthlink.net
> Linux. Because life's too short for a buggy OS.
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com

Yes. That is (kinda) what I was looking for.
More specifically, I would like to take some action
just after the parent process forks, but before it actually
exec's the child. This action should configure the child
such that it is not allowed to over-commit, but instead
must die if it can not get the memory it needs.

We have experimented with system-wide changes to the
over-commit policy, but apparently option 2 (strict over-commit)
is buggy.

I can't afford to patch the OS at this time as that would require
patching thousands of machines from the US to China (in my
multi-national corp.)

Bill