> Mike Harrelson writes the following:
> >
> >According to a Sun engineer, Solaris 2.6 does not support memory overcommit.
> >Normally Solaris manages memory by reserving virtual memory for all processes,
> >whether they use utilize it or not. When virtual memory has been fully
> >reserved, then malloc()'s, fork()'s, etc may then fail with the 'Resource
> >temporaily unvailable', even though the physical swap may be hardly touched.
>
> And I suppose Sun is constantly flooded with complaints along these lines:
>
> "Hey! I allocated all the memory in my system, and your crappy OS said I
> couldn't allocate any more! How dare you put reliability ahead of hackish
> optimizations! I demand lazy, unsafe vm that can cause any process to die
> randomly at any time even though it has done nothing wrong!"
>
> I don't say this often, but perhaps we should take a lesson from Solaris
> here.
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...
-- mikeh
-
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/