Tuning memory-bound systems

If the system is found to be memory bound there are a number of things that can be done. The most obvious and that which will probably bring the most benefit is to add more physical memory to your system and retune it. If this is not possible then a number of alternatives exist:

• Determine if a number of memory intensive processes are being run simultaneously. This can be done by running ps -el. The SZ value gives the virtual memory (swappable) size of the process's stack and data (both initialized and uninitialized) regions in 1KB units. If many memory intensive processes are being run simultaneously then rescheduling these jobs to run at alternative times will redistribute the use of memory. To see if any memory-intensive jobs running at peak times can be rescheduled, you should also check the system's crontab(C) files.

  It is also possible that some applications programs may have a memory leak and are continuously increasing their size in virtual memory. If you suspect that an application has a memory leak, you should restart the program before its usage of virtual memory starts to make the system swap or page out. You may notice this problem with server processes that run continuously for several weeks.

• If you are writing your own applications, use static shared or dynamic linked libraries to make more efficient use of memory.

  You should also ensure that the applications do not have a memory leak.

• Reduce the size of the kernel to free more user memory. This can be done by reducing the size of the buffer cache as discussed in ``Increasing memory by reducing the buffer cache size''.

If the system appears to be constantly paging, this may be the result of the values of GPGSLO and GPGSHI being too high. This causes vhand to page out pages while a large number of free pages still exist. Lowering these values could delay the onset of paging but might cause the system to begin swapping out whole processes instead if memory drops to zero. If no compromise can be met then the system needs more memory.

If the number of pages on the free list falls below GPGSLO, vhand begins moving pages out of memory. vhand continues to do this until the number of pages on the free list reaches GPGSHI.

If the difference between GPGSLO and GPGSHI is too great, this may cause an I/O bottleneck while the kernel attempts to write the contents of many dirty pages to disk.

If the values of GPGSLO and GPGSHI are close together, vhand will be active for a shorter period of time but more often. If vhand is constantly active, its usage of the CPU may degrade performance.