List of processes attached to shared memory

[Fedon Kadifeli]

I get the following output from "ipcs -mp"

T ID KEY MODE OWNER GROUP CPID LPID
...
m 63004 0x00000000 D-rw-r----- oracle dba 3919 4346
m 5 0x00000000 D-rw-r----- oracle dba 3919 4346
...

These segments look removed. However since some processes are attached to them, the system cannot remove them. The attached processes are not 3919, neither 4346. How can I find which process uses these segments?

I was not able to find such an information in gpm or lsof...

[Devbinder Singh Marway]

if you do ipcs -a , what is shown in the NATTACH column if 0 then nothing is attached , so using ipcrm you can remove the shared memory entry. Is this the case ?

[Fedon Kadifeli]

There seem some processes attached:

# ipcs -mo
IPC status from /dev/kmem as of Fri Jan 5 12:50:18 2001
T ID KEY MODE OWNER GROUP NATTCH
Shared Memory:
...
m 63004 0x00000000 D-rw-r----- oracle dba 2
m 5 0x00000000 D-rw-r----- oracle dba 4

I want to find out what they are...

[CHRIS_ANORUO]

Hi Fedon,

Try ipcs -t to find out if the OTIME has no-entry(without time) and also ipcs -mob to get the id's.
You can remove the shared memory id's with ipcrm -m id number.
You can also try lsof to get the exact process attached to the shared memory segment.
http://gatekeep.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.51/

[Fedon Kadifeli]

I *do* have lsof, but I couldn't find an option in lsof to display the processes attached to a specific memory or the memory regions a specific process is attached to.

BTW: Full "ipcs -ma" output is as follows:

T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 63004 0x00000000 D-rw-r----- oracle dba oracle dba 2 819200000 3919 4346 8:43:40 8:43:40 8:43:40
m 5 0x00000000 D-rw-r----- oracle dba oracle dba 4 557936640 3919 4346 8:43:40 8:43:40 8:43:40

[Fedon Kadifeli]

I tried to remove the memory segment, but the system refuses to remove the shared memory:

# ipcrm -m 63004
ipcrm: shmid(63004): not found

Now, we are stuck! We *have* to release that 1.3 GB of memory, but how can we do it without rebooting the system?

[Mike Stroyan]

This program will print information about all of the memory regions that are mapped by all running processes. System V shared memory regions show up as type PS_SHARED_MEMORY.
There is no ipc id in the information about the memory regions. If you are looking for a 1.3GB region, then it should be easy to pick it out by the pst_length value. That is the size of the region measured in 4KB pages.

[Wodisch]

Hello Fedon,
since you are talking about shared memory beeing used
by oracle, why not using "svrmgrl"? Do something like:
su - oracle
svrmgrl
connect internal
shutdown abort
exit
exit

Usually that is pretty safe - except if you are not up to
date with oracle-patches! Your really need patches, if
you have a *.*.*.0.0 release! (Like 8.1.6.0.0, or even
7.3.4.0.0, I have seen that problem often then!)
HTH,
Wodisch

[Fedon Kadifeli]

After investigating the problem with all the indirect methods to find out who is using the shared memory regions, I came to a conclusion that *no process in system is using these regions*. But, I still can't remove these regions because the system thinks that somebody is using them. I think there is a bug in the kernel that counts incorrectly the processes attached to a shared memory.

Now, the problem is: Since this is a production system (this means that I cannot reboot the system at my will) how can I change these incorrect counts and set them to zero, so the shared memory can be removed, without rebooting the box. Is there any Q4 expert or kernel debugger out there to help me!?

[Steven Sim Kok Leong]

Hi,

Oracle uses both shared memory and semaphores. In addition to shared memory, semaphores should also be checked via ipcs. If the Oracle semaphores had not been released previously during an Oracle shutdown, they have to be manually removed via ipcrm. Otherwise, Oracle may have difficulty in starting up.

Hope this helps. Regards.

Steven Sim
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Ovidiu D. Raita]

Is Oracle down? If yes, whay don't you kill all the processes that belong to oracle:dba?

Ovidiu

[Fedon Kadifeli]

A new instance of Oracle is running and I'm sure that no process is attached to this shared memory. In other words shutting down Oracle will not help. The problem is with the system. I think we have to reboot the system to clear the memory, but this is a production V2600 system, so cannot reboot it right now. I want to clear the memory without rebooting.

[Steve Bonds · Accepted solution]

Sure, it's been 9 years, but this is still in the top results from Googling.

Using the HP-provided "kmeminfo" utility like this gives tons of good info:

kmeminfo -shmem

For example if "ipcs -m" shows:

-----
T ID KEY MODE OWNER GROUP
Shared Memory:
m 0 0x41181147 --rw-rw-rw- root root
m 1 0x4e0c0002 --rw-rw-rw- root root
m 2 0x411c0b3b --rw-rw-rw- root root
m 3 0x411898ef --rw------- root root

-----

Use kmeminfo like this:

-----
# ./kmeminfo -shmem 2
... trimmed ...
Processes using this segment:
proc=0x52ac4000 (pid 749 "nktl_daemon")
proc=0x52ac8000 (pid 759 "ntl_reader")
-----

And there you have the two PIDs attached to that shared memory segment.

Now you know what to kill or shut down to free up that segment.

-- Steve