possibly strange ipcs information

[Peter Heinemann]

In investigating an Oracle out of memory error, we notice the following in ipcs:

m 119306 0x00000000 --rw-r----- oracle dba oracle dba 78 1073741824 9508 28604 14:35:20 14:31:58 19:37:28
m 11 0xf15b0654 --rw-r----- oracle dba oracle dba 78 606052352 9508 28604 14:35:20 14:35:20 19:37:28

My understanding is that a 0 value KEY with a 78 NATTCH value is abnormal. True? Any others with experience with this condition, specifically Oracle (9.2, hpux 11.11)

Thanks.

[Mark Greene_1]

Are you questioning the 78, or any non-zero value?

We have an HP-UX 11.11 system running Oracle (8.something I think), and ipcs -a returns these:

m 8 0x00000000 D-rw------- root root root root 11 1052672 2514 2514 1:20:47 no-entry 1:20:47
m 9 0x00000000 D-rw------- ccuser dba root root 11 184324 2515 2515 1:20:49 no-entry 1:20:49

So the combination of a 0 value key and a non-zero NATTCH appears to be valid. None of the half-dozen oracle processes on our system had zero value key, so this may be an apples-to-oranges comparision.

mark

[Peter Heinemann]

Right.

It was the condition of zero KEY with non-zero NATTCH.

[A. Clay Stephenson]

The answer is "it depends" but "quite probably okay".

A shared memory key of 0 simply means than the original shmget() was called using the IPC_PRIVATE (which itself is zero) for the key argument. The intent is to create a unique shared memory identifier that will never be returned by another call to shmget() until the identifier has been released via shmctl(). IPC_PRIVATE is used to set up a shared memory segment that will be accessed by a parent process and its children. The number of attaches could be many or only a few --- it depends upon the application.