Shared memory issues

[John Huck]

I have some 32 bit applications (omniback, and others) that are reporting errors similar to the following:

Cannot allocate shared memory pool (IPC Cannot Create Shared Memory Segment
System error: [12] Not enough space

I can't see that I'm even close to the 2gb limit of shared memory for 32bit apps. Here is some additional info.

Kernel parms:
shmem 1
shmmax 0x7FFFFFFF
shmni 1024
shmseg 1024

ipcs reports:
Shared Memory:
m 1024 0x33440e7e --rw------- root sys 2153624
m 1 0x4e0c0002 --rw-rw-rw- root root 61760
m 2 0x4130639c --rw-rw-rw- root root 8192
m 11267 0xffffffff --rw-r--rw- root root 22908
m 4 0x0c6629c9 --rw-r----- root root 18163120
m 5 0x06347849 --rw-rw-rw- root root 77384
m 7174 0x00000000 D-rw------- root root 2153624
m 7 0x6d440081 --rw-rw-rw- root root 47120
m 6152 0x00000000 D-rw------- web mis 46084
m 2057 0x5e280032 --rw------- root root 512
m 46090 0x52624801 --rw-rw---- root informix 588267520
m 16395 0x52624802 --rw-rw-rw- root informix 1130496


Any ideas what might be causing this?

Thanks
Huck

[James R. Ferguson]

Hi:

Fragmentation in the shared memory pool is one cause of this error.

Regards!

...JRF...

[Bill Hassell · Accepted solution]

There is only 1 map for all 32bit shared memory segments and each segment must be contiguous. If someone uses (the very bad) kill -9 command to terminate a program, old segments will be left behind. Also, the segments can't be moved so small segments can end up in the middle of an otherwise large chunk of memory.

While you can experiment with ipcrm but you can easily destory an active segment as there are no locks to prevent removing a segment that is in use. A reboot will solve the problem, but if it comes back again, you'll need to look at memory windows to isolate certain applications so they have their own memory map. The program shminfo will show the actual map contents. Get a copy from:

ftp://hprc.external.hp.com/sysadmin/programs/shminfo

[John Huck]

Thanks, I downloaded shminfo... but what am I looking at exactly? I've attached the output. I see a lot of OTHER and FREE lines, and a few that show SHMEM id=. Nothing looks unusualy to me though and it doesn't look like there are even that many in use.

Thanks

[Bill Hassell]

You are looking for the free space. Unfortunately, you need to know how much RAM is being requested by Omniback and that depends on the size of the backup (all the filenames, sizes, paths, etc are stored in shared memory). If you find that the largest free area in the shminfo map is 200 megs, then that is your problem. You can stop Informix to free up some space, then run Omniback. Biut Manipulatintg the programs to fit into this (very restrictive) memory map is a big job. I would suggest creating a memory window to handle Omniback, perhaps another to handle Informix. Now each app sees an empty map with lots of empty space.