allocation of shared memory

[Jan Meijer]

Hi,

We?ve got a problem with Ingres allocating shared memory. The Ingres error message:

shmget() failed with operating system error 12 (Not enough space)

According to /usr/include/sys/errno.h, value 12 corresponds with error code ENOMEM.
Shmget(2) explains ENOMEM: "(...) the amount of available physical memory is not sufficient (...)".

The system on which it?s running: N4000/8, phys mem 4GB, device swap 4GB, UX 11.0, swapmem_on=1.

Now I?ve got a few questions about shared memory and memory allocation:
1) Must shared memory be allocated in physical memory? If so, why? Virtual memory on the system isn?t exhausted, physical memory is: Reserved swap is about 70%, physical memory is 100%.
2) We use the original kernel parameter settings for buffer cache (min=5, max=50). I know the second value is quite large and we should set it below 30. What I?d like to know about buffer cache is, how is it managed? When a machine runs out of physical memory (which appears to be our situation), why is the buffer cache not reduced to it?s minimum? While Ingres had problems allocating shared memory, buffer cache didn?t drop below 1.4 GB, which is 35%.
3) The Ingres server processes that use shared memory, do each allocate a large amount of memory. Output of GlancePlus: Shmem RSS/VSS: 240Mb/260Mb (which by the way suggests that shared memory can be allocated in virtual memory). The processes which should have shared regions do all allocate some 200MB, which doesn?t seem shared to me. Does anyone know what?s going on here?

Thanks in advance,
Eisse

[Andy Monks]

shared memory uses virtual memory, however as every process needs access to it, it therefore limits the amount in total you can have (1.75/2.75gb depending on patches and O/S level assuming 32bit).

If you do an 'ipcs -mob' you can total up the size of all your segments and see how much your currently using. If your using under 1.75gb and the additional amount should fit into that gap, then you probably have shared memory fragmentation. In which case, you will either have to start processes in a specific order.

You might also want to contact your local HP response center about an unsupported program called shminfo. It will show you the virtual addresses being used for shared memory/shared libs and mmap'ed files (which is where ipcs falls down quite badly).

[John Palmer]

There are a couple of useful documents installed in /usr/share/doc on your 11.00 server.

mem_mgt.txt is the HP-UX memory management white paper.

mem_wndws.txt is the Memory Windows white paper and it describes how you can create multiple 'windows' of shared memory segments up to the 1.75Gb limit for 32 bit processes.

Regards,
John

[Jan Meijer]

Thank you both for your answers. We?ll investigate shared memory usage and how to implement memory windows. I?ll save my buffer cache questions for some other occasion.

[John Palmer]

The buffer cache will reduce as memory pressure increases. In fact the size of the cache gives you a good idea of how much memory pressure the system is under.

It's likely that in your case you were either trying to exceed the 1.75Gb limit for 32bit shared memory (no windowing) or existing shared memory was fragmented such that you couldn't allocate a single segment of the size that Ingres requested. You would need to check with the ipcs command.

Regards,
John