Re: A question on shared memory usage

In article <34DF0E07.32C6@bloomberg.com>, Art S. Kagel <kagel@bloomberg.com> writes >com@netinfo.moldova.net wrote: >> >> Hello, >> >> In article <34dcff94.500279443@10.209.30.200>, >> jharris@westpac.com.au wrote: >> > >> > Octav, >> > >> > Once Infomrix allocates a shared memory segment it is not >> > automatically freed when no longer needed. >> > >> > To make online free shared memeory segments do >> > onmode -f>> > >> >> Of course I understand this. But my question wasn't about >> shared memory segments. It was about the session memory usage >> inside a (or some) shared memory segments. The count of blocks used >> inside a shared memory segment is shown as --blkused-- by >> onstat -g seg. And this blocks should be freed (in my opinion) as>> soon as a session is freeing some resources (cursors, statements). >> So, the question is: why the count of blocks used in a shared memory >> segment doesn't change when I close and FREE the cursor ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^ >> > >The memory used by your cursors and prepared statements (4GL >implicitely prepares statements even if you did not explicitely prepare >any) is freed when the cursor is freed. The communications areas ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But apparently that is NOT happening. What I believe may be happening is this. The session allocated fragments of memory (onstat -g afr) which are grouped into pools. Globally the amount of free memory as seen by onstat -g seg also decreases. When the memory is not needed the memory within the pool allocated to the session is freed hence you can have free fragements (onstat -g ffr) however the memory is NOT returned back to the global free memory as seen by onstat -g seg. Kind of like UNIX and malloc. malloc is really built on top of the UNIX sbrk call which controls the end address of memory allocated as seen by UNIX. However malloc does NOT always keep calling sbek to allocate and free memory. Instead malloc handles the allocation and freeing of smaller memory chunks (arenas) itself because it is more efficent then to keep on calling UNIX. I suppose Online is similar as it thinks that if your sessions needed x Mb of memory then it may need it again (e.g. it may free a cursor now but it will probably soon prepare anotehr cursor). Allocating memory and freeing it at the global level must be controlled via a mutex to avoid sessions allocating the same memory twice. By allowing sessions to keep the memory they have previosuly allocated and freed this should reuce contention for this mutex between sessions and hence give better performance. This assumes the memory requirements for a session will grow to a certain value and then remain constant. Of course during quiet times you may be able to afford the CPU time to return these fragments back to the 'global' pool and hence onmode -F was born. NOTE: THIS IS ALL MY THEORIZING By hey, that is how I would do it... >allocated to support your query were freed when your program exited, >they are kept for reuse until then, but the connection specific >data structures allocated in shared memory are not freed when your >program exits. They are kept for future reuse by another process >to connect with. You should see that if another copy of the process is >executed after the first has exited that the memory used does not >continue to increase but that the allocated structures are reused. > >Art S. Kagel -- David Williams Maintainer of the Informix FAQ Primary site (Beta Version) http://www.smooth1.demon.co.uk Official site http://www.iiug.org/techinfo/faq/faq_top.html I see you standin', Standin' on your own, It's such a lonely place for you, For you to be If you need a shoulder, Or if you need a friend, I'll be here standing, Until the bitter end... So don't chastise me Or think I, I mean you harm... All I ever wanted Was for you To know that I care