shared memory / ipcs

[Greg Geyer]

Linux system running SAP. Now I'm not a great diagnoser of ipcs output but this seems odd to me. On my HP-UX systems running large SAP instances the largest NATTCH # is usually <100 and is never more than the total # of processes on the box.

If you notice below (just looking at the shared memory segments without a key) the largest segment has a NATTACH # of 6129. Is this symptomatic of bad shared memory usage by the applications, or simply a different method than what I'd see with HP-UX? There's <200 processes running at the moment.

(underlines mine to keep spacing)


:~ # ipcs -m | grep 0x00000000
key_______shmid______owner_____perms____bytes___nattch__status
0x00000000_147816448__sapadm____701__131072______2
0x00000000_143163393___sapadm____701__131072______2
0x00000000_163844______dr1fenc1____701__23052288____50
0x00000000_294919______sapadm____777__1024________1
0x00000000_10747921____sapadm____777__12582912000_6129__dest

[Court Campbell]

That is more than likely an old SAP instance that was not shutdown properly of failed. The status of dest means that the segment is marked to be destroyed. You remove it like this

# ipcrm shm 10747921

You can also get more info on the segment by running:

# ipcs -m -i 10747921

[Court Campbell]

I guess I could also note that when you run

# ipcs -m -i 10747921

look at the cpid. That should be the process that created the segment. You could then grep ps for that pid to see if it is still running or you could

# kill -0 pid

If it states that there is no such process, you could ipcrm the shm.

[Greg Geyer]

Court,

Thanks for the reply. The kicker is that that the PID does exist...it is basically the root SAP process that all the other work processes in SAP spawn from (its the parent of 40 more processes). It is active and this symptom is exhibited by other SAP on Linux systems we have.

I suspect it is the type of Linux we're using (ZLinux/Suse on a mainframe!). Yes, IBM product but I'm mostly an HP guy so thought I'd post here.

Shared memory Segment shmid=10747921
uid=27902 gid=1001 cuid=27902 cgid=1001
mode=01777 access_perms=0777
bytes=12582912000 lpid=7190 cpid=2835 nattch=10346
att_time=Wed Nov 7 11:26:36 2007
det_time=Wed Nov 7 11:25:41 2007
change_time=Sun Nov 4 13:07:00 2007

:~ # date
Wed Nov 7 11:26:39 MST 2007

I wouldn't care but I'm working an issue that may or may not be shm related. Probably will just let the IBM/SAP people review.

Thanks - G.

[skt_skt]

i do see similar things on my RHEL servers.An appl support person would be able to tell more about the need of that processes.