What is using your shared memory?

Jeroen de Meijer

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

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.

Happy hunting!


you might also like