Hi,

I have some shared memory questions and I hope to find knowledgeable persons concerning this topic.

1/ I have shmseg == 360 and in the ipcs -am output I see ID's 0 to 357.
Some of the ID's have a higher number:

0, 1, 2, 3357, 4, 5, 232111, 65234, 8, 9, etc.

Can I assume that these are not always real identifiers, but that they act more like a slot ?

I do see that all ID's have a CPID / LPID assigned, so it is a bit confusing.

What do the higher numbers mean ?

2/ When I count the total segsz, I come to 1884138022 bytes.
That is about 1796.85 Mbytes.
I heard about a limitation of 1.75 Gb or 2.75Gb, so it looks like either all available space is filled, or I am hitting a boundary.

Is there more info on this ?

3/ In some article I read that the shared memory ID is being used as a file descriptor which can be found in lsof (the NODE column).
I did some cross checks, but was not able to make this mapping.
Specially since for instance ID 2 is present many, many times in lsof.

Any one out there that tried the same ?


Background is that when I restart for example an Oracle DB, I sometimes get file system full error, or when I restart another process, it fails too due to a lack of shared memory.
So I think there are some applications/processes that do not release their segments.

Greetings,

E.J.

The maximum shared memory on HP-UX 11.11 is about 1.75 Gb. It doesn't matter how much you try to allocate in the kernel, it will never address more. It is important to keep your shared memory requests below the maximum and that you have enough free physical memory to match. Your Oracle DBA should be able to tell you how much shared memory each Oracle instance is asking for and HP "glance" program (option "t") can show you total being used and how many sempahores are in use.


Btw. "filesystem full" is about disc space not memory.

Thanks for answering.

The usage of the server is not limited to Oracle only and therefore more programs/processes are using shared memory and "fighting" for a share.

When everything is running there is no problem; they all co-exist in harmony (or at least appear to do so).
But sometimes when a large consumer of shared memory is being restarted (like oraclecdb), it can happen that the necessary space is not present anymore as an other process took some.

I think I know which application/program is responsible, but I need some proof.
Understanding the ps, ipcs, lsof, glance, etc data would help me a bit.
And also without this problem present, it is nice to gain some indepth knowledge.

Thanks for the tip on glance, I completely forgot about it.
I will take a look at its output in order to see if it helps to understand the big picture.

Btw, I quoted the wrong error message. The real one is:

"HP-UX Error: 28: No space left on device"

#define ENOSPC 28 /* No space left on device */

"[ENOSPC] A shared memory identifier is to be created but the system-imposed limit on the maximum number of allowed shared memory identifiers system wide would be exceeded."

When this happens, always the maximum number of shared memory segments has been reached (shmmni 6144).

E.J.

---------- Post updated at 06:00 PM ---------- Previous update was at 04:39 PM ----------

Just FYI, for those interested.

glance option t:

System Table Available Used
--------------------------------------------
Shared Mem Table (shmmni) 6144 358
Semaphore Table (semmni) 4096 41

This is the same as:

kmtune | grep shmmni | awk '{print $2}'
ipcs -am | grep '^m' | wc -l

and

kmtune | grep semmni | awk '{print $2}'
ipcs -as | grep '^s' | wc -l

The 'Semaphore Table - Used' count is only the number of semaphore sets in use.
To know the number of actual used semaphores, you need to add up all NSEMS values.

E.J.