We have a lot of Oracle database running on our Solaris systems. And they all use shared memory. It might be interesting to know how many of that shared memory is used, and maybe also which database is using how much of the available shared memory. The first is easy, the latter a bit more difficult.
On most systems the amount of shared memory is set to a maximum. You can do this in /etc/system, but this is ‘evil’. If you do this, you’d better rev up your knowledge of Solaris. This should be done in /etc/project.
In below example a project has been created. This project, group.dba, is a special project. All processes started with groupid dba will be automatically in this project. As all database in this project run with groupid dba, all the database will be in this project.
root@host:~# cat /etc/project system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: group.dba:1000::::project.max-shm-memory=(privileged,16106127360,deny)
You can also see that a resource setting is added to the group specification; project.max-shm-memory, defining the maximum amount of shared memory the project may use. In this case 16 GByte.
Next thing to found out is how much shared memory is used. The ipcs (inter-process communication facilities status) is the tool for this.
root@host:~# ipcs -mp IPC status from
as of Thu Sep 11 10:42:20 CEST 2014 T ID KEY MODE OWNER GROUP CPID LPID Shared Memory: m 50331688 0x60758e0 --rw-r----- oracle dba 10028 14668 m 67108903 0 --rw-r----- oracle dba 10028 14668 m 2080374822 0 --rw-r----- oracle dba 10028 14668 m 1929379876 0x9c7cce44 --rw-r----- oracle dba 11447 14610 m 1979711559 0x497d7bc8 --rw-rw---- oracle dba 16849 14666 m 1962934342 0 --rw-rw---- oracle dba 16849 14666 m 1845493829 0 --rw-rw---- oracle dba 16849 14666 m 771752024 0x68d83d68 --rw-rw---- oracle dba 3694 13418
It shows the amount of shared memory used by which creating process id (CPID) en which process id last accessed (LPID) this block of shared memory.
We can see four different CPIDs in the listing; so we have four processes using shared memory.
Now it is just adding up the numbers.
Total of shared memory used is 9.95 GByte of a maximum of 16 GByte as we saw before. We have ample of shared memory left.
CPID 10028 is using 2 GByte of shared memory
CPID 11447 is using 1.8 GByte of shared memory
CPID 16849 is using 5.4 GByte of shared memory
CPID 3694 is using 0.72 GByte of share memory
Now the hard part. We seem to have four database on the system:
root@host:~# ps -ef | grep -v grep | grep pmon oracle 3696 797 0 Mar 29 ? 42:20 ora_pmon_database1 oracle 16853 797 0 Sep 07 ? 0:59 ora_pmon_database2 oracle 10034 797 0 01:22:16 ? 0:07 ora_pmon_database4 oracle 11462 797 0 21:06:57 ? 0:09 ora_pmon_database3
Put you can’t easily match these processes to the share memory segment. The creating PID does no longer exist, and a lot of short lived child processes access the shared memory segment. So the LPID changes every time. You have to be quick and a bit lucky.
You run ipcs -mp, and try as quickly as possible grep for one of the LPID’s. And after a few time you will be lucky and get something like
root@host:~# ps -ef | grep 14666 oracle 14666 797 0 10:42:16 ? 0:00 ora_j001_database4 root 14778 14179 0 10:42:38 pts/2 0:00 grep 14666
Now we know that the share memory segment of LPID 14666 (and thus CPID 16849) is related to database4. So database 4 is using 5.4 GByte of shared memory.