Excess V-segment allocation - who's responsible?

HP-UX 11i (aka 11.11), IDS 9.30HC5 Our system runs well and within its initial Virtual shared memory allocation of 400Mb most of the time, but every now and then it goes mad and allocates load of SHMADD-sized Vsegs sized at 8Mb (where loads >=8), which as we all know, is not good on HP. Rather than just set the initial Vseg size to 500M or something (which we'll do anyway, next restart), it'd be nice to find out just what app has caused the extra allocation. There are some JDBC connections which we know are notorious for memory leaks and we're watching them, but most of our processes are 4Gl and run on the same machine as the engine. So; can we tell what process 'owns' the extra segments? Thanks Malc

"Malc P" <malc_p@btinternet.com> wrote in message news:8c28402a.0403110504.4912faef@posting.google.com... > HP-UX 11i (aka 11.11), IDS 9.30HC5 > Our system runs well and within its initial Virtual shared memory > allocation of 400Mb most of the time, but every now and then it goes > mad and allocates load of SHMADD-sized Vsegs sized at 8Mb (where loads > >=8), which as we all know, is not good on HP. > Rather than just set the initial Vseg size to 500M or something (which > we'll do anyway, next restart), it'd be nice to find out just what app > has caused the extra allocation. > There are some JDBC connections which we know are notorious for memory > leaks and we're watching them, but most of our processes are 4Gl and > run on the same machine as the engine. > So; can we tell what process 'owns' the extra segments? > Thanks > Malc The online.log shows the times at which the segments were added. Could this help you narrow down the rogue processes?

Yup, we've got monitoring (hourly) looking at total shared memory allocated to informix, so I've put alarms on this so that we can have a look at the 'hot' times. I'm pretty convinced it's the JDBC connections, but the point I really want to clear up is whether there's any way of investigating the extra segments (e.g. with onstat -g stk, and knowing the address of the segment in memory) to find out what process (or owner) caused the engine to allocate it. Thanks Malc