Re: memory pools

bala peddi wrote: > Could Any one Please explain me the memory Pools section of > onstat -g ses 12378 > Is this the normal in informix > INFORMIX-OnLine Version 7.23.UC2 -- On-Line -- Up 13 days 18:11:16 -- > 416472 Kbytes > session #RSAM total used > id user tty pid hostname threads memory memory > 691 navuser console 1894 cali.fmr 1 344064 155496 > tid name rstcb flags curstk status > 16576 sqlexec c03fb58 Y--P--- 1872 c03fb58 cond wait(netnorm) > Memory pools count 4 > name class addr totalsize freesize #allocfrag #freefrag > 691 V c79a018 245760 108616 419 48 > 691_SORT_0 V c2c2018 32768 32024 12 5 > 691_SORT_1 V c91e018 32768 15904 7 2 > 691_SORT_2 V c9f0018 32768 32024 12 5 > Last parsed SQL statement : > select parent_type, parent_code, > child_sort_order,child_type,child_code,child_desc from> t_rollup_and_desc > where parent_type = 'FG' order by 1,2,3 Sure, the memory pools are sections of Online's shared memory allocated to your session's threads or various purposes, communications buffer for returned data (the first segment shown), sort work areas (you have three of these), DSS memory, etc. This is essentially normal except: You do have a problem. The report shows that there is no current SQL statement outstanding but you still have the sort-work areas allocated from the last statement. These should have been freed, returned to the pool. This usually indicates a process that has not closed and its cursors or has reopened them without closing if there is a current statement that does not require a sort. Check out your source and fix this as it can cause the shared memory allocated to this session to grow uncontrolled until it forces the engine to allocate a new dynamic segment to keep up. If the last two columns of onstat -g ses; are continually increasing over time then this is definitely happening and you can watch the available pool memory shrink with onstat -g seg (watch the virtual segment, class "V" blkused and blkfree columns over time). Art S. Kagel