Shared memory cleanup

[Sreekanth Makam_1]

Hi folks,
In the system there are many shared memory segments with user as root. I got this from command ipcs -m
.I started some processes through root and they created so many shared memories. I want to now delete them .I can use ipcrm -m for this.
But the problem is if use ipcs -m, it is showing only user id.
How to find , which shared memories belongs to me?
Please help me in this regard as early as possible...because there are so many shared mem and i am about to run out of memory.
One thing i can do is restart the system.. But that is very bad way of doing the things

Ok folks help me..fast plzz

[Amit Dixit_2]

Sreekanth,
Try ipcs -mac,
Hope this helps to identify shared memory
which you can delete.

Thanks,
Amit.

[Sridhar Bhaskarla · Accepted solution]

Hi Sreekanth,

You will get the PIDs of the process that created and that last accessed with 'ipcs -ma' command. Look at CPID and LPID columns. Also see "NATTCH" column. It indicates the number of processes that are attached now to this segment. If you see it 0 and if you don't find both CPID and LPID (pids of the processes that created and last accessed respectively)in the process list (ps), you can probably remove the segment. Again, pay atmost attention and verify things twice before you remove.

-Sri

[Hein van den Heuvel]

Can you tell those sections apartm like from a create time?

If so, try sometking like:

ipcs -ma | awk '/x:xx:xx/{system("ipcrm -m " $2)}'


Enjoy,
Hein.

[A. Clay Stephenson]

Without knowing the underlying software, it's not possible to do this safely.

The most important word in the following is "PROBABLY":
"If you see it 0 and if you don't find both CPID and LPID (pids of the processes that created and last accessed respectively)in the process list (ps), you can probably remove the segment."

NATTACH being zero is a necessary but not necessarily sufficient condition for the removal of a shmid. It all depends on how the software using the shmid was written. For example, it rather common to have a process initialize a chunk of shared memory and them exit. Naatach is now zero, there are now active PID's associated with the shmid BUT if another process depends upon the shmid being there, it will die when the shared memory segment can't be found. This second process which needs the shmid might not be launched for days after the shared memory segment was initially created and populated with data. The moral of this is know your applications.

[Sreekanth Makam_1]

Yes Stephenson is correct, Knowing the application is very importent to startup..

But my job is this. I am testing an application, which writen by some body( I cannot find them now) and studying the shared memory usage. I found that shared memory cleanup is doing by app. So I want to clean manually by hand for each run. In parllel some other team will look about this problem.
So my question, what is the exact and eligent way of cleaning shm mems.
I did'nt found LPID and CPID's in ps -ef, but NATTACHï¼ 0. So what I can do...
There are more than 500 shm's..And I want to make a clean run every time.

[Sreekanth Makam_1]

Sorry I miss type some things above..
1. Shared mem is not cleaned by app.
2. NATTACH > 0
.
One more question..
If the KEY = 0x0000000, and MODE=D-rw-rw-rw-
, According to me, that is detached and i can safly delete that shm mem.
Is that right.???

[Sridhar Bhaskarla]

Hi Sreekanth,

Well, in your case it's for sure a dirty job.

Usually applications do provide some debugging information like shmids at the time of shared memory creations or somewhere in the log files that indicate shmids. If the process is active, then you may get them if you run 'tusc'. I have a feeling that your application leaving some 'jombies' behind. and they are attached to the shared memory segments (hence NATTCH > 0). Your app is trying to delete the shared memory segment but since it is attached to those jombies, it's marked with a "D" is waiting for the jombies to terminate.

Now the question is how many such shared segments are seen with "D" Mode?. All 500?. In that case you will need to cleanup the processes rather than shared memory segments.

-Sri

[Bill Hassell]

Since the application is improperly written (does not clean up shared memory), you have three choices:

1. If all the bad program segments are the same size, just use the ipcs remove command and see if any of the programs start crashing.

2. Remove the bad programs from the system so they won't interfere with normal operations. This is especially true for production systems that cannot go down due to programming errors.

3. Reboot the system.

Because the programs are so badly written, there is no 'correct' way to pick the segments for removal. Only the original programmer (hopefully) knows how to figure this out. Give the programmer a new job: shared memory manager

[Sreekanth Makam_1]

Hi sridhar,
There are very less with "D" i.e., <5.

[Hein van den Heuvel]

>> There are more than 500 shm's..And I want to make a clean run every time

Did you see my earlier suggestion?

ipcs -ma | awk '/x:xx:xx/{system("ipcrm -m " $2)}'

This works very nicely for me for broken applications that do not clean up.
The trick is to put in the right 'xxxxxx'.
For me that is simply the username for the bad application.
For you it might be a size or a create time.

If there are still attaches, then at least the sections will become marked for delete and will go away when you kill the processes attached to it.

Hein

[Sreekanth Makam_1]

Hi,

I always deleted all shm's which have the user id as mine. The problem here is I have shm's created by root. Because I run some users by root user.

[Sreekanth Makam_1]

Hi folks,

Thanks for your valueble time.

The conclutions are:
1. First check the app, rather than try how to delete them.
2. try ipcs -ma to get LPID,CPID and NATTACH and depending on these values , confirm to delete it or not.

Thanks,
Sree