SHMTOTAL tuning question

[WiccaChic]

Hey all. My SHMTOTAL setting is 0 on my test box, which means unlimited and I think this is causing a problem with some network services whenevr the database really gets pegged. The server has 1 gig of real memory, so I figured I would set SHMTOTAL to 800,000 (a little over 3/4 of the real memory I think!?) in order to prevent Informix from taking the entire box's mem.

When I tried to fire up the database, I got this error:
size of resident + virtual segments
670225240 + 307200000 > 819200000 total allowed by configuration parameter SHMTOTAL

I was not sure how to change the settings that were totaling more than my 800,000K so I just changed it back to 0. Can someone advise please? I want to leave the server enough room to breath when the database is totally tied in a knot.

 

[vpshriyan]

Hi,

I do not think that "SHMTOTAL 0" specification causing problem in network services, unless informix dbserver engine has gobbled up extremely huge chunk of real memory. This scenario seems to be far remote, that too, in a test server!

You can verify the memory used by dbserver by:
onstat -

You can get component level (Resident,Virtual & Message) details of shared memory by:
onstat -g seg

You can also verify the additional virtual memory segments added up dynamically by the engine at runtime by in the last 200 lines of engine message log:
tail -200 `onstat -c | grep MSGPATH | awk '{print $2}'` | grep 'dynamically allocated'

After scanning the results of the above, if you feel that the engine has "captured" more memory than it should, you may have a look at the following $ONCONFIG parameters with have a direct bearing on the memory, and scale down the values appropriately.
LOCKS # Maximum number of locks
BUFFERS # Maximum number of shared buffers
SHMVIRTSIZE # initial virtual shared memory segment size
SHMADD # Size of new shared memory segments (Kbytes)

Regards,
Shriyan
"Vision is the art of seeing things invisible."

 

[WiccaChic]

I am pretty sure informix is grabbing all the memory when a particularly huge and clumsy stored procedure executes. I have sort of proven this theory out because when this particular SP is running, my incoming network connectrions slow down and eventually stall out and if I kill the session running that SP...bam!...everything is back to normal.

Developers are working on the SP, but I still would like to prevent IDS from doing this in the future by giving it a ceiling. Is there an equation I can use that says if SHMTOTAL = A then these other memory specific settings should be B, C, D, E...etc...?

 

[ids2000]

In fact, there is not an oficial formula to find out the best SHMTOTAL suitable value.
But you can use this to make your own formula:
These are the ONCONFIG parameters which afects the shared memory size:

LOCKS + BUFFERS + SHMVIRTSIZE + SHMADD + NETTYPE

Running *** onstat -g seg ***, you should find three kinds of segments: (V)irtual portion, (M)essage portion and the (R)esident portion.

The sum of these three portions cannot overpass the SHMTOTAL parameter.

Virtual Portion:
SHMVIRTSIZE (kb)
SHMADD (kb)
Resident Portion:
LOCKS (each lock holds 44 bytes)
BUFFERS (pages)
Message Portion
NETTYPE
It only appears when using onipcshm connections, creating a pool in the shared memory.

Tune your engine so these parameters do not overpass the SHMTOTAL, giving extra kb's for some SHMADD segments.

Particulary, I use about 80% of the total physical size of memory in the machine.

FFO
"The only way of knowing is to understand"

 

[WiccaChic]

Thanks much IDS2000! I was thinking 80% as well, just clumsily did not understand the other parms.
-wc