Several performance tools provide reports of memory usage. The reports of most interest are from vmstat, ps, and svmon.
vmstat summarizes the total "active" virtual memory used by all of the processes in the system, as well as the number of real-memory page frames on the free list. Active virtual memory is defined as the number of virtual-memory working-segment pages that have actually been touched. It is usually equal to the number of paging-space slots that have been assigned. This number can be larger than the number of real page frames in the machine, since some of the active virtual-memory pages may have been written out to paging space.
ps provides several different reports of memory use, depending on the flag used. The most comprehensive comes with ps v, which displays the following memory-related columns:
| SIZE | Virtual size in kilobytes of the data section of the process. (Displayed as SZ by other flags.) This number is equal to the number of working-segment pages of the process that have been touched (that is, the number of paging-space slots that have been allocated) times 4. If some working-segment pages are currently paged out, this number is larger than the amount of real memory being used. |
| RSS | Real-memory (resident set) size in kilobytes of the process. This number is equal to the sum of the number of working-segment and code-segment pages in memory times 4. Remember that code-segment pages are shared among all of the currently running instances of the program. If 26 ksh processes are running, only one copy of any given page of the ksh executable would be in memory, but ps would report that code-segment size as part of the RSS of each instance of ksh. |
| TSIZ | Size of text (shared-program) image. This is the size of the text section of the executable file. Pages of the text section of the executable are only brought into memory when they are touched, i.e., branched to or loaded from. This number represents only an upper bound on the amount of text that could be loaded. |
| TRS | Size of the resident set (real memory) of text. This is the number of code-segment pages times 4. As was noted earlier, this number exaggerates memory use for programs of which multiple instances are running. |
| %MEM | Calculated as the sum of the number of working-segment and code-segment pages in memory times 4 (that is, the RSS value), divided by the size of the real memory of the machine in KB, times 100, rounded to the nearest full percentage point. This value attempts to convey the percentage of real memory being used by the process. Unfortunately, like RSS, it tends the exaggerate the cost of a process that is sharing program text with other processes. Further, the rounding to the nearest percentage point causes all of the processes in the system that have RSS values under .005 times real memory size to have a %MEM of 0.0. |
As you can see, reporting memory statistics in a format that was designed for earlier, simpler systems sometimes results in distorted data.
svmon provides both global, process-level, and segment-level reporting of memory use. For tuning purposes, the -G and -P options are most interesting.
| -G | Summarizes the memory use for the entire system. |
| -P | Shows the memory use for one or more processes. |
In AIX Version 4, the svmon command is packaged as part of the Performance Toolbox for AIX. To determine whether svmon is available, use:
lslpp -lI perfagent.tools
If this package has been installed, svmon is available.
The following example shows the output of these commands on a large system. vmstat was run in a separate window while ps and svmon were running consecutively. The vmstat summary (first) line has been removed:
$ vmstat 5 procs memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 25270 2691 0 0 0 0 0 0 142 2012 41 4 11 86 0 1 0 25244 2722 0 0 0 0 0 0 138 6752 39 20 70 10 0 0 0 25244 2722 0 0 0 0 0 0 128 61 34 0 1 99 0 0 0 25244 2722 0 0 0 0 0 0 137 163 41 1 4 95 0
The global svmon report below shows related numbers. The number that vmstat reports as Active Virtual Memory (avm) is reported by svmon as page-space slots in use (25270). The number of page frames on the free list (2691) is identical in both reports. The number of pages pinned (2157) is a separate report, since the pinned pages are included in the pages in use.
$ svmon -G
m e m o r y i n u s e p i n p g s p a c e
size inuse free pin work pers clnt work pers clnt size inuse
24576 21885 2691 2157 13172 7899 814 2157 0 0 40960 25270
Singling out a particular, long-running process on this machine, we can compare the ps v and svmon -P reports. The actual program has been renamed anon.
$ ps v 35851 PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND 35851 - S 0:03 494 1192 2696 xx 1147 1380 0.2 3.0 anon
The SIZE value (1192) is the svmon Pgspace number (298) times four. The RSS value (2696) is equal to the number of pages in the process private segment (329) plus the number of pages in the code segment (345) times four. The TSIZE number is not related to real-memory use. The TRS value (1380) is equal to the number of pages in use in the code segment (345) times four. The %MEM is the RSS value, divided by the size of real memory in KB, times 100, rounded to the nearest full percentage point.
$ svmon -P 35851 Pid Command Inuse Pin Pgspace 35851 anon 2410 2 4624 Pid: 35851 Command: anon Segid Type Description Inuse Pin Pgspace Address Range 18a3 pers /dev/hd2:5150 1 0 0 0..0 9873 pers /dev/hd2:66256 1 0 0 0..0 4809 work shared library 1734 0 4326 0..4668 : 60123..65535 748e work private 329 2 298 0..423 : 65402..65535 2105 pers code,/dev/hd2:4492 345 0 0 0..402
As we analyze various processes in the environment, we observe that the shared library is indeed shared among almost all of the processes in the system, so its memory requirement is part of overall system overhead. Segment 9873 is also widely used, so we can include its memory in overhead. If one were estimating the memory requirement for program anon, the formula would be:
The total memory requirement for anon is equal to 345*4KB for program text (shared among all users) plus the estimated number of simultaneous users of anon times the sum of the working-segment size (329*4KB) and 4KB for the mapped segment (segment ID 18a3 in this example).
A memory leak is a program bug that consists of repeatedly allocating memory, using it, and then neglecting to free it. A memory leak in a long-running program, such as an interactive application, is a serious problem, because it can result in memory fragmentation and the accumulation of large numbers of mostly garbage-filled pages in real memory and page space. Systems have been known to run out of page space because of a memory leak in a single program.
A memory leak can be detected with svmon, by looking for processes whose working segment continually grows. Identifying the offending subroutine or line of code is more difficult, especially in AIXwindows applications, which generate large numbers of malloc and free calls. Some third-party programs exist for analyzing memory leaks, but they require access to the program source code.
Some uses of realloc, while not actually programming errors, can have the same effect as a memory leak. If a program frequently uses realloc to increase the size of a data area, the process's working segment can become increasingly fragmented if the storage released by realloc cannot be re-used for anything else. (Appendix F, Application Memory Management-malloc and realloc, contains background information on malloc and realloc.)
In general, memory that is no longer required should be released with free, if the memory will probably be re-used by the program. On the other hand, it is a waste of CPU time to free memory after the last malloc. When the program terminates, its working segment is destroyed and the real-memory page frames that contained working-segment data are added to the free list.
The vmstat, ps, and svmon commands.