A first performance look on AIX: vmstat, svmon, topas, nmon, and paging space

What it is

AIX's standard performance-first-look tools are vmstat, svmon, topas and nmon; none of them mirror Linux's free/top column layout exactly, and AIX's virtual-memory accounting distinguishes computational (working-set/program) pages from non-computational pages (mainly file cache) in a way Linux's memory counters do not present directly.

• vmstat -Itw 2 5 (interval and count; without them vmstat prints a single line of averages since boot) reports, among other columns, avm (active virtual memory, in 4 KB pages) and fre (free memory); dividing avm by 256 converts it to megabytes.
• svmon -G (normally run as root) gives a system-wide memory snapshot in the same 4 KB units; svmon -P breaks it down per process, useful for finding the largest virtual-memory consumers.
• topas shows memory as a computational percentage — the figure to watch for over-commitment, since it excludes file cache.
• nmon (interactively, pressing "m" for the memory screen) reports a combined "used" percentage that mixes computational and non-computational memory; it is not a like-for-like substitute for topas's computational figure and should not be read as the over-commitment indicator by itself.
• lsps -a displays paging space characteristics: name, hosting physical volume/volume group, size, percent used, and active/inactive state. Paging space usage is a secondary indicator: IBM's guidance is that the system starts paging out when computational memory reaches about 98% of physical memory (file cache is reclaimed first), so rising lsps -a usage is a symptom to investigate, not the primary measurement to tune against.

Why it matters

Reading nmon's aggregate "used%" as if it were topas's computational percentage, or reading vmstat's avm while ignoring that pinned memory and file cache are not reflected in it, produces a false read on whether an LPAR is actually short of memory. Because paging space is markedly slower than RAM, the documented recommendation when paging space usage climbs is to investigate and increase memory, not to grow paging space as the fix.

How to apply

• Start with vmstat -Itw 2 5 for a quick avm/fre read (and the pi/po paging-space columns), converting avm to megabytes by dividing by 256.
• Cross-check with svmon -G (system-wide) or svmon -P (top per-process virtual-memory consumers) when a specific workload is suspect.
• Use topas's computational percentage, not nmon's combined used percentage, when the question is specifically memory over-commitment.
• Check lsps -a as a corroborating signal, and treat sustained high paging-space usage as a reason to review memory sizing rather than paging-space sizing.

Pitfalls

• Quoting nmon's "used%" as the over-commitment figure; it includes non-computational memory such as file cache.
• Relying on avm alone: pinned memory and file cache do not show up in it, so a low fre with a healthy avm still needs a look at svmon -G.
• Reacting to paging-space growth by resizing paging space instead of investigating memory demand.