[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/