Aug 28

The controls for IPC settings such as shared memory and semaphores have changes somewhat in Solaris 10. This seems to be a cause of regular confusion, and recently a friend asked me to clarify how they ought to be configured.

The new facilities in Solaris 10 makes such settings dynamic, but the controls to prevent overallocation are still there, albeit in a slightly modified form.

There are two approaches these days..

  1. /etc/system (yawn, requires a reboot - why would you?)
  2. Projects

The IPC settings are entirely controlled by projects these days.. the ability to set values in /etc/system is there solely for backwards compatibility, and simply sets the default values for the projects, and therefore should be considered deprecated.

Probably the best way to explain the use of projects to set default values is to run through a quick worked example of setting the shared memory max allocation (shmmax), with comments inline:


$ uname -a
SunOS deepthought 5.11 snv_69 i86pc i386 i86pc

It's reporting 5.11 as it's an OpenSolaris build, but same priciples apply to 5.10
$ id -a
uid=500(mike) gid=100(users) groups=100(users)

The user we're running as has no specific privs, such as would be the case with an Oracle application account (for example). There is no settings in /etc/system, so we're running with default values.

As an aside, this is running under VMware server on a Linux host with 256MB memory allocated to the VM. The default value of shmmax is calculated as physmem/4, so we ought to see maximum allocation around about 64MB

We can check what the max shm is going to be using Solaris 10 prctl command:


$ prctl -n project.max-shm-memory $$
process: 6905: ksh -o vi
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
project.max-shm-memory
privileged 61.9MB - deny -
system 16.0EB max deny -
$

That's reporting 61.9MB, which is pretty close to the expected 64MB. I wonder where the other 3.1MB went?

And to prove the point, I've just written a wee program that tests this, by creating (and destroying) increasingly large segments of shared memory (incrememnting by 1MB at each iteration). It stops when it fails and reports the last created seg.


$ ./findmax
Shared seg created with 61.0 MB
shmget failed!
$

So, here's how we increase it.. We need root privs, or a friendly sysadmin for this, as we're adding a new project for this user only:


$ su
Password:
# projadd -U mike -K "project.max-shm-memory=(priv,80MB,deny)" user.mike
#

Back on as me now.. (notice I'm logging on again by su'ing back to myself, rather than just exiting the "su" shell - this is deliberate)


# su - mike
Sun Microsystems Inc.   SunOS 5.11      snv_69  October 2007
$ prctl -n project.max-shm-memory $$
process: 7044: ksh
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
project.max-shm-memory
privileged 80.0MB - deny -
system 16.0EB max deny -
$
$ ./findmax
Shared seg created with 80.0 MB
shmget failed!
$

Posted by Mike Scott

| Top Exits (0)

0 Trackbacks

  1. No Trackbacks

2 Comments

Display comments as(Linear | Threaded)
  1. Xeleema says:

    Mike, I have to admit that I've found a couple of very helpful things on your blog. Any chance we'll see another post soon?

    Keep up the good fight!

  2. Mike says:

    I've kinda been away from the deep technical stuff for a while, which is probably why I stopped.

    However, I'll see what I can do ;-)

Add Comment


Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA