RE: Excess V-segment allocation - who's responsible?

I've had my share of problems with this. I have a cron job that I run every 5 minutes that looks in MSGPATH for new shared memory segments and if any are found logs session infor for the users with the highest total shared memory. Let me know if you want a copy. #!/bin/ksh # # FILENAME # check_shm # SYNTAX # check_shm -d SECONDS -n NUM_USERS [-t TESTFILE ] [-v] # # DESCRIPTION # script to check for new shared memory segments allocated and # find out who's the memory hog, logs session info for users# with the most total memory # -s SECONDS - time in seconds to bo back through the online log # looking for new shm segments # -n NUM_USERS - the number of users to log session info for # if we allocated new shm segments # -t TESTFILE - for testing # -v for verbose mode # Regards, Bill > -----Original Message----- > From: Neil Truby [SMTP:neil.truby@ardenta.com] > Sent: Thursday, March 11, 2004 8:34 AM > To: informix-list@iiug.org > Subject: Re: Excess V-segment allocation - who's responsible? > > "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? > sending to informix-list