mechanisms of HP-UX for releasing shared memory

[Stefano_1]

I have a problem with the mechanisms of HP-UX for releasing shared memory.
When the segment is removed, it is not effectively removed until each process attached reseleases it (during this time, 'ipcs' command shows a 'D' at the permissions of the concerned segment).
We have a couple of problems with this:

. Even if the process that are attached to a shared mem segment release it, when destroying the shared memory segment it is not effectively removed until we kill these processes.
(the destroyed shared memory segment is an ERDB database that is stopped, the process are Sema application process that release the shared memory).
Could someone help me?
Thanks in advance

[Alexander M. Ermes]

Hi there.
The shared mem behaves like an open file.
As long as there are processes connected to it, it will not be released, otherwise the process would panic.
If you delete a large file, you will only notice, that the space is free only, if the processes accessing it are killed ( lsof ).
Same with shared mem. You have relative adresses in this memory area belonging to the process ( hash tables etc ). They can only be released with the death of the process.
Rgds
alexander M. Ermes

[Bill Hassell]

The purpose of shared memory is to allow multiple processes to access the same data areas. To destroy a shared memory area while processes that use it are still running would surely cause bad things to happen to the programs.

Normally, processes that use shared memory are started and terminated in a formal manner in order to properly share and close data areas. Killing arbitrary processes would not be a very good way to stop the process group. Check with your software vendor to see what the proper way would be to terminate the processes so that shared memory can be released.

[A. Clay Stephenson]

Hi Stefano,

It appears that everything is working normally.
It is possible to remove a shared memory segment while the processes that created/attached them are still active - but you have to follow the rules.

1) Each process should call shmdt().

2) One process should call shmctl(my_shmid,IPC_RMID,&dummy).

Actually, step 2 can precede step 1 and when the the attach count drops to zero the shm segment and all data structures associated with it are removed.

Hope this helps, Clay

[Stefano_1]

Sorry,I forgot a piece of problem....



when the segment is removed, it is not effectively removed until each process attached reseleases it (during this time, 'ipcs' command shows a 'D' at the permissions of the concerned segment).
We have a couple of problems with this:

. Even if the process that are attached to a shared mem segment release it, when destroying the shared memory segment it is not effectively removed until we kill these processes.
(the destroyed shared memory segment is an ERDB database that is stopped, the process are Sema application process that release the shared memory).

. It seems to be a strange limit in the allocation of shared memory in our configuration:
even if we have 3,5Gb of RAM, it seems that concerning the shared memory, there is a top
much before. In fact, after removing a 720 Mb shared mem segment (when stopping the ERDB database), the segment remains "hang" (even if destroyed, it is not effectively released as
there are still process living but not attached), and when trying to get a new 720Mb segment (starting the ERDB database again), there is "no room" for both. The Sema applications have other shared memory segments that are quite litle (less
than 3Mb in total). Other sw running is IPlanet sw (Web Server and Directory server) and Orbix (Corba implementation).Other strange thing is that we have two machines apparently equal, but concerning this
"limitation" of shared memory allocation they behave in different way: one of them has room for this 720 Mb + 720 Mb + other Mb (two DB and the rest), and the other one no. In all the cases,
even the one that has room for "all" (two DB and the rest), does not have room for "much more" (strange as there are 3.5Gbytes of physical RAM plus swap space).
The fact is that apart from this behaviors, we do not know how to:
. check which processes are attached (hanging effectively in some way) to a particular shared mem segment.
. check the size of the actual shared memory segments not belonging to "Sema/ERDB"
. In HP-UX there is not a clear way to monitorize the RAM/swap memory (the columns in vmstat are particular and do not reflect the unit used, the swapinfo should not be
related to physical but only swaped memory). Our only way is to use the top command(that in HP-UX only can be interactive).
The problem seems to be related only to shared memory allocation and not conventional memory.

thanks for your help

[A. Clay Stephenson]

Hi Stefano,

This may be as simple as increasing the SHMMAX
parameter. What OS are you running? The shared memory limit vary with the OS.

[Stefano_1]

HP_UX 11.00.01 on a Stratus platform.
At the moment the shmmax is set to 1073741824.
What do you think ?