Shared Memory Limits for HP11 and Informix

[Nathan Jones_8]

I'm so confused....I've been reading through many posts in the last hour about this, and I feel like I'm reading a lot of conflicting data.

On particular HP/Informix 2000 box, we have 8 instances of Informix running, and are running out of shared memory. All instances are using the 32bit version of the Informix engine.

Questions:

1. What is the max amount of shared memory that can be used between all instances? I've read 1.75GB, is that correct?

2. If I do chatr -M on the instances, that will give me 2.75GB collectively? If so, what happens if I just do it to one instance? Will that one have 2.75GB available, and the others are still limited to 1.75GB? If so, it would see the other would no longer be able to allocate any more since that chatr'd instance pushed the total over 1.75GBs. That make sense?

3. Is there any danger to doing chatr? These are production instances, so its freaking us out a bit.

Thanks in advance!
Nate

[Warren_9]

hi,

white paper /usr/share/doc/mem_wndws.txt answer question 1 and 2.

1. 1.75 is corrent
2. it depends on the executable is complied with the memory magic option.
3. no idea in 11 ... but in 10.20 there is a patch for improve the performance of
shmem_magic executables.

GOOD LUCK!

[A. Clay Stephenson]

If these instances do are truly separate then the solution is memory windows. Do a search for "memory windows". The idea is that each group of related processes gets its own 4GB virtual address space rather than shaing a common one as 32-bit processes
normally do. Whether or not a process can use
1.75 or 2.75 GB of shared memory depends upon what options it was originally compiled with. If, for example, -N was not specified then chatr can help you. Man cc for details.

[A. Clay Stephenson]

Ooops, I meant unless compiled with the proper options, chatr can't help you.

[Bill Hassell]

For 32 bit programs, there is one map--period. All 32bit programs but share that same map *BUT* the map can becomne fragmented as you stop and restart processes that use shared memory. And if anyone uses kill -9 on shared memory programs, the shared memory is not returned (never use kill -9 on database programs). So the address space allows for 1750 megs of RAM (or 2700 or 3700, see below) but you can't add the total usage because some segments may not fit. While ipcs -bmop will show you the current segments, it cannot show you fragmentation. You need a copy of the shminfo program from HP:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/

Now to address larger amounts of RAM (beyond 1750megs), you need use -Wl -N for compile options, then use chatr to enable q3p and q4p. NOTE: This just enables a program to request larger amounts of RAM. The request will be rejected if the requested chunk size cannot be found. As Clay mentioned, the best solution is to give each database instance it's own map with memory windows.