Virtual Memory Segment Filling Up

We are using IDS 10.00.uc7 on AIX and we are noticing that shared virtual memory segments keeps growing, and we end up having to restart the informix to clean up the memory. Is there any way to determine which session id are using up what virtual memory ? What sql statements are using up the virtual memory segments ? Thanks in advance for any help and pointers provided. Thanks Prasun

Hi, try "onstat -g ses" as user informix for a start. To get details on a specific session do "onstat -g ses <session ID>". Further drill down might be done with "onstat -g afr <session ID>" and "onstat -g ffr <session ID>". Info on SQL statements you can also find by issuing "onstat -g sql <session ID>". I think in 10.00 there is no SQL statement history. :-( That feature was added later to newer versions of IDS only. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management Notes: Martin Fuerderer/Germany/IBM@IBMDE IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 04.11.2008 21:04:40: > We are using IDS 10.00.uc7 on AIX and we are noticing that shared virtual > memory segments keeps growing, and we end up having to restart the > informix to > clean up the memory. > > Is there any way to determine which session id are using up what virtual > memory ? > What sql statements are using up the virtual memory segments ? > > Thanks in advance for any help and pointers provided. > > Thanks > Prasun > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi Prasun, as Martin already said, start with "onstat -g ses". onstat -g ses | sort -nrk 7 | head This will tell you your top sessions sorted by their memory usage. You probably have prepared statements not closed in those sessions. To check for that pick the top one session ID and continue with: onstat -g stm <session ID> Look for re-occurrences of the same SQL statement(s) there and fix the apps accordingly. Cheers Davorin