Re: onstat -g ses

>Hi, >In the onstat -g ses output , what is the basis for allocation of 'total >memory' ? >There is also the figure 'used memory' , why not just allocate required >memory ? Well, we could do that but then that would 1) fragment memory and 2) create bottlenecks. Memory in shared memory is allocated in large blocks of 4K and is maintained via a bit map. When memory is allocated by a thread, it is associated with a pool. The thread can then allocate/free memory within that pool as it needs. The memory within that pool is then allocated and freed as needed and is maintained via an allocated linked list and a free linked list. There is some overhead with maintaining the linked list and searching for where the allocation can be made. The pool has to be locked while memory is being allocated from that pool, but it is only locked to threads requesting memory from that pool. Most of the allocations are made from the session's memory pool. There is one for each session. That means that as one thread is allocating memory from it's session pool, it is not preventing other threads from allocating from their memory pools. We have multiple memory pools because the life and scope of each memory pool is different. For instance, each session has it's own session memory pool. There are a couple of global pools, such as the dictionary information, which exist as long as online is active. While the thread is doing a sort, it may aquire a sort pool which is then release once the sort is complete. For those situations where we might need to allocate memory for a short duration, we might chose to use a heap plan. With this, we don't actually free the memory, we just free the entire heap. For instance, during the optimization phase of a query we have requirements for a lot of rather small memory buffers. Once the optimization phase is complete, none of that memory is needed agaion. Instead of going through the overhead of freeing each memory buffer that might be allocated from the heap, the entire heap is freed at once. This allows us to "pop" an allocation from the heap and completly free all of the heap memory as soon as that phase of processing is complete. Madison Pruet