Weird behaviour when setting shared memory parameters in /etc/system

From: Russell Page (russellpage@hotmail.com)
Date: Tue Jun 21 2005 - 01:23:26 EDT


I'm running a number of Sparc systems all running Solaris 8. I recently
installed an app (TrendMicro Internet Web Security Suite) that uses
PostgreSQL as a back-end database on one of them. The tuning document that
comes with the app suggests the following settings be made in /etc/system:

set shmsys:shminfo_shmmax=0x300000
set semsys:seminfo_semmni=512
set semsys:seminfor_semmns=512

I made these changes and rebooted the system.
About six hours later the CPU was running at 100%, and there were 30 virus
scanner daemons running, all apparently "busy looping" in user-land.

Among the things I did to try and work out what was going on was to run up
adb on the running kernel and checked the various things I had set in
/etc/system. I found that the value for shminfo_shmmax was 0.

I tried setting it on a test box, with the same result. - Note I tried
different, smaller values and tried using decimal rather than hex, but
always the value seen by adb was 0.

Cockcroft and Pettit - "Sun Performance and Tuning" has this to say about
shmmax:

"The maximum size of a shared memory segment. The largest value a program
can use in a call to shmget(2). Setting this tunable to a high value doesn't
impact anything because kernel resources are not preallocated with this
value."

My question: Is there a problem here? I have a vague recollection of hearing
once that some tunables actually behave like this: You set a value, but that
is in fact a limit, and the value that you see when you inspect the kernel
might be something else - or was I dreaming?

-- Russell Page.

Certified Solaris Network Administrator
Metaphors be with you.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:56 EDT