Memory Tuning
| Memory Tuning | ||||||
|
Apart from re-writing or modifying the application then there are very parameters that control the memory used by the engine
Big segments not small ones, drop back to Unix for explanation why it is bad to have lots of small segments The onstat -g seg command displays the shared memory segment information. Segment Summary: (resident segments are not locked) id key addr size ovhd class blkused blkfree 0 1381451777 a000000 2727936 868 R 329 4 1 1381451778 a29a000 8192000 720 V 333 667 2 1381451779 aa6a000 155648 596 M 16 3 3 1381451790 aae7000 155648 596 M 0 19 Total: - - 11075584 - - 678 693 The onmode -F command will free segments that are not in use. It does this, via the MGM which examines every memory pool and frees the unused memory, and then it examines each segment and will release to the OS any segments that are unused. This can be a CPU intensive operation and sime degradation of performance while this command is being run should be expected. | ||||||
| A Memory Leak | ||||||
|
Any driver that uses Kernel Memory Allocator (KMA) resources, but does not specifically release them before exiting can create a memory leak. A memory leak causes the amount of memory allocated by KMA to increase over time. Thus, if the alloc field increases steadily over time, they may be a memory leak. Another indication of a memory leak is failed requests. If this occurs, then it is likely that a memory leak has caused KMA to be unable to reserve and allocate memory. Detecting memory leaks on a live system can be very difficult. [The DBAudit demo shows a memory leak on a production system, caused by faulty datablade] However, if luxury of a test system is available then it is relatively straightforward to monitor the engine's memory usage and determine whether it is slowly increasing over time. |

