lkml.org 
[lkml]   [1998]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Out Of Memory in v. 2.1
In <Pine.GSO.4.03.9810070126360.9883-100000@gcedunet.gcsu.edu>, on
10/07/98
at 01:40 AM, Mike Harrelson <mikeh@mindspring.net> said:

[not having overcommit]
>Well, it keeps Solaris from thrashing, but it can be quite a nuisance. We
>had to move off of Solaris to DEC UNIX because we just couldn't afford to
>stick 4+GB of swap on every machine when none of it was hardly used.
>When you serve over a thousand web sites in the Apache conf file on a
>single machine, the size of each daemon grows significantly. Then you
>run hundreds of daemons to serve the web sites and before you know it,
>all of the swap/mem is gone (reserved). The real killer was Stronghold.
>When each daemon got to be around 30+MB each with around 50 running,
>reserved swap disappeared quickly. Since these daemons share memory
>(via COW), little physical swap is actually used. Our situation is a bit
>extreme, but it can demonstrate a bad side to Solaris's memory
>management. If only it could be toggled...

A toggle looks like a good idea. Most people could use overcommitment and
possibly some intelligent oom-killer, while those who need reliability
could turn off overcommitment and reserve a lot of swap space.

A limit on overcommitment might be useful compromise. I.e. you can
overcommit up to x times the size of availavle virtual memory, but then
malloc/fork start to fail. x would be a tuneable parameter. A skilled
malicious user might still be able to bring down a machine, but a good
value for x would minimize the need for extra swap space while also
preventing a burst of web or mail activity from killing the machine or
activating a less than perfect oom-killer.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.106 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site