Hello,

i have seen an interessting thing on AIX the last days: it kills
processes when it comes to an overcommit on memory, i.e. the systems can
give memory exceeding the "virtual memory". Linux and BSD have similar
OutOfMem-Killers. does something similar exist in Solaris?

I dont think this is an usefull behavior, but overcommiting memory is
interesting idea, since every project claims to need a lot of memory
which is not used in fact.


I run some tests and see that Solaris can give away nearly all virtuall
memory, but do not overcommit.
Nevertheless there are some questions:

a) can Solaris overcommit memory like Linux/AIX/BSD, e.g. by tunables?

b) what happens to the kernel, when all virtuell memory is filled and
e.g. a kernel module must be loaded, maybe a driver, or a cronjob
starts or a daemon forks. Does it panic, or just dont start new memory
eaters?

c) since what version of Solaris you dont have to reserve
"swap space"="physical memory", i remember 5.6 rightly?

d) is there a tunable to limit usage of swap as space for paging (not
the parameter limit for tmpfs) global or for processes? I think there is
something for virtual memory.

e) I have seen there was an kernel tunable for the reserved paging
space, how big is it on typically system (sorry, no pdf by hand) and is
there a tunable for this reserved for kernel memory usage.

Please dont send me to "SOlaris INternals", the Memory part is one of
the hardest to me ;-(, and I have not found the answers for the OOM Case
for kernel, s. b).

THanks
Wolfgang

Wolfgang <wtrappe@AT.web.de> writes:

>i have seen an interessting thing on AIX the last days: it kills
>processes when it comes to an overcommit on memory, i.e. the systems can
>give memory exceeding the "virtual memory". Linux and BSD have similar
>OutOfMem-Killers. does something similar exist in Solaris?

No, Solaris does not generally over commit memory with on exception:
process and thread stacks and memory mmaped with MAP_NORESERVE.

Memory allocated will be available when used; the only thing that can
cause a process to die is when it attempts to grow its stack and
there is no more memory available.

>I dont think this is an usefull behavior, but overcommiting memory is
>interesting idea, since every project claims to need a lot of memory
>which is not used in fact.

Right; that's why you'd want to have swap space; it's cheap and it's
where unused memory can be reserved from (swap -s ' reserved column)

>a) can Solaris overcommit memory like Linux/AIX/BSD, e.g. by tunables?

No, except for the exceptions listed above.

>b) what happens to the kernel, when all virtuell memory is filled and
>e.g. a kernel module must be loaded, maybe a driver, or a cronjob
>starts or a daemon forks. Does it panic, or just dont start new memory
>eaters?

In the kernel one of two things can happen: the memory allocation fails
or the system will wait until memory becomes available.

System calls like fork() will fail with an appropriate error code.
The system should not panic.

>c) since what version of Solaris you dont have to reserve
>"swap space"="physical memory", i remember 5.6 rightly?

Never in Solaris 2.x; the system runs without swap space.

>d) is there a tunable to limit usage of swap as space for paging (not
>the parameter limit for tmpfs) global or for processes? I think there is
>something for virtual memory.

No. The system doesn't really distinguish between memory uses in that
way (all you can do is limit swap space but that has effects on
everything)

>e) I have seen there was an kernel tunable for the reserved paging
>space, how big is it on typically system (sorry, no pdf by hand) and is
>there a tunable for this reserved for kernel memory usage.

The system tries to keep a small percentage of memory free at all times.

That's not really a tunable (it's self-tuned)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Mar 20, 8:27 am, Wolfgang <wtra...@AT.web.de> wrote:

> I run some tests and see that Solaris can give away nearly all virtuall
> memory, but do not overcommit.
> Nevertheless there are some questions:
>
> a) can Solaris overcommit memory like Linux/AIX/BSD, e.g. by tunables?

Everything Casper said is, of course, right. There is a good paper
which describes some of the issues with overcommit:
http://developers.sun.com/solaris/ar...ry_arrays.html.

One of the problems with overcommit as naïvely implemented is that
there's really no correlation between the process which causes the
immediate problem (shortage of memory) and the actual bad guy. So the
OOM killer often can kill completely the wrong process, which is a bad
thing.

Tim Bradshaw <tfb+google@tfeb.org> writes:

>On Mar 20, 8:27 am, Wolfgang <wtra...@AT.web.de> wrote:

>> I run some tests and see that Solaris can give away nearly all virtuall
>> memory, but do not overcommit.
>> Nevertheless there are some questions:
>>
>> a) can Solaris overcommit memory like Linux/AIX/BSD, e.g. by tunables?

>Everything Casper said is, of course, right. There is a good paper
>which describes some of the issues with overcommit:
>http://developers.sun.com/solaris/ar...ry_arrays.html.

>One of the problems with overcommit as na=EFvely implemented is that
>there's really no correlation between the process which causes the
>immediate problem (shortage of memory) and the actual bad guy. So the
>OOM killer often can kill completely the wrong process, which is a bad
>thing.

I've heard of an implementation which targeted the largest process and
ended up killing the most important process (Oracle, IIRC)

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik schrieb:
> Tim Bradshaw <tfb+google@tfeb.org> writes:
>
>> On Mar 20, 8:27 am, Wolfgang <wtra...@AT.web.de> wrote:
>
>>> I run some tests and see that Solaris can give away nearly all virtuall
>>> memory, but do not overcommit.
>>> Nevertheless there are some questions:
>>>
>>> a) can Solaris overcommit memory like Linux/AIX/BSD, e.g. by tunables?
>
>> Everything Casper said is, of course, right. There is a good paper
>> which describes some of the issues with overcommit:
>> http://developers.sun.com/solaris/ar...ry_arrays.html.
>
>> One of the problems with overcommit as na=EFvely implemented is that
>> there's really no correlation between the process which causes the
>> immediate problem (shortage of memory) and the actual bad guy. So the
>> OOM killer often can kill completely the wrong process, which is a bad
>> thing.
>
> I've heard of an implementation which targeted the largest process and
> ended up killing the most important process (Oracle, IIRC)
>
> Casper

yes, in our case the cluster processes are been killed, which are not a
good idea ....

In article <47e22cb2$0$14352$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> Wolfgang <wtrappe@AT.web.de> writes:
>
>>b) what happens to the kernel, when all virtuell memory is filled and
>>e.g. a kernel module must be loaded, maybe a driver, or a cronjob
>>starts or a daemon forks. Does it panic, or just dont start new memory
>>eaters?
>
> In the kernel one of two things can happen: the memory allocation fails
> or the system will wait until memory becomes available.

Before we got to that point, there's some active purging such as
unloading kernel modules which are not currently in use.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

On 20 Mar 2008 11:08:37 GMT, Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> Tim Bradshaw <tfb+google@tfeb.org> writes:
>>One of the problems with overcommit as naívely implemented is that
>>there's really no correlation between the process which causes the
>>immediate problem (shortage of memory) and the actual bad guy. So the
>>OOM killer often can kill completely the wrong process, which is a bad
>>thing.
>
> I've heard of an implementation which targeted the largest process and
> ended up killing the most important process (Oracle, IIRC)

Heh, that must have been lots of fun

I've seen OOM kill a named process which happened to have a very large
cache too. Amusing but annoying after the second time it happened.

Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> I've seen OOM kill a named process which happened to have a very large
> cache too. Amusing but annoying after the second time it happened.

http://lkml.org/lkml/2004/9/23/311

--
Daniel