A question on shared memory usage 
Author Message
 A question on shared memory usage

Quote:

> Hello,



> > 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
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



Wed, 18 Jun 1902 08:00:00 GMT
 A question on shared memory usage



Quote:

>> Hello,



>> > 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 ?

           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
           ^^^^^^^  
Quote:

>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...

Quote:
>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



Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. Shared Virtual Memory Usage Question

2. Shared pool memory usage

3. Checking shared memory usage

4. Informix 7.11: Optical / Blobs and shared memory usage

5. 6.0 Shared Memory Usage

6. ADO Causes 100% Memory Usage/Increases in VM Usage

7. SQL memory usage question

8. Memory Usage question

9. Memory usage question

10. memory usage questions

11. Memory Usage Question

12. Sybase V5.0 Memory Usage Question


 
Powered by phpBB® Forum Software