Messages in this thread | | | From | "Helge Hafting" <> | Date | Wed, 07 Oct 1998 08:57:06 +0100 | Subject | Re: 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/
| |