Learn about performance tuning in this excerpt from the book Driving the Power of AIX.

In this chapter, I identify and show you how to tune your virtual memory subsystem. In contrast to other subsystems, there is a lot you can do to improve performance from a virtual memory perspective.

Before we get started, let me again state that, unless instructed otherwise, you should change only one parameter at a time. If you make multiple changes, you won't know precisely what caused the impact on performance. This point is particularly relevant to virtual memory.

vmo

vmo -h [tunable] | {-L [tunable]} | {-x [tunable]}

vmo [-p|-r] (-a | {-o tunable})

vmo [-p|-r] (-D | ({-d tunable} {-o tunable=value}))

Let us assume that we're running an Oracle online transaction processing (OLTP) application and we've determined from some vmstat output that the system is paging. We've also looked at nmon data, which helped us reach the same conclusion. What can we do to improve the situation? This is where the vmo command comes into play.

You will probably use vmo more than any other tunable command because it is with virtual memory that you have the greatest ability to positively affect performance by changing parameters. The vmo command provides a staggering 61 tunables in AIX 5.3. (The situation changes a bit in AIX 6.1 with the introduction of restricted parameters, which permit changes but make it a little more difficult to get into trouble.) I won't describe each vmo parameter here, but I will go through the key ones as we try to tune our memory subsystem.

minperm, maxperm, maxclient, and lru_file_repage

Perhaps the most important concepts that relate to tuning revolve around our prior discussions about working and persistent storage. We definitely want the Virtual Memory Manager (VMM) to favor working storage, meaning that we don't want AIX to page working storage. What we really want is for the system to favor the caching that the database (Oracle in this case) uses. The way to do this is to set the vmo command's maxperm parameter to a high enough value while also making certain that the lru_file_repage parameter is set correctly. Here's a description of the involved parameters:

• minperm% — The point below which the page stealer algorithm will steal file or computational pages, regardless of repaging rates
• maxperm% — The point above which the page stealer will steal only file pages
• maxclient% — The minimum percentage of RAM that can be used to cache client pages
• lru_file_repage — Setting this value to 0 (off) allows AIX to free only file cache memory (provided numperm is greater than minperm and VMM can steal enough memory to satisfy demand), virtually guaranteeing that working storage remains in memory

Background

Arguably, the most important vmo settings are minperm% and maxperm%. Setting these parameters appropriately will ensure that your system is tuned to favor either computational memory or file memory. In most cases, you don't want to page working segments, because doing so will cause your system to page unnecessarily and will decrease performance.

First, some background and history. The way things used to work was actually much simpler. If the number of file pages specified in vmo parameter numperm% was greater than the actual number of pages (maxperm), the page replacement would steal only file pages. When the number of file pages fell below minperm, both file and computational pages could be stolen. If the number fell between the minimum and maximum values, the page replacement would steal only file pages—unless the number of file repages was greater than the number of computational pages. In other words, if your numperm was greater than maxperm, you would start to steal from persistent storage.

Based on this methodology, the old approach to tuning minperm and maxperm was to set maxperm to a low number—much lower than the default value (20)—and set minperm to less than or equal to 10. This is how we normally would have tuned our database server. Don't do this anymore! Starting with AIX 5.2 Maintenance Level 5 (ML5) and AIX 5.3 ML2, the rules have changed.

A New Approach

The new approach is to set maxperm to a very high value—higher than its default (80)—and to make sure lru_file_repage is set to 0. IBM introduced the lru_file_repage parameter in AIX 5.2 with ML4 and in AIX 5.3 with ML1. The lru_file_repage value indicates whether the VMM repage counts should be considered and what type of memory should be stolen. The default setting is 1 (it becomes 0 in AIX 6.1), so we need to change it to 0 to have the VMM steal file pages rather than computational pages. This technique solves the old problem of having to limit JFS2 file cache to guarantee memory for applications such as Oracle.

Let's not lose sight of the fact that the primary reason you need to tune lru_file_repage is because you want to protect the computational memory—that is, process memory, kernel memory, and shared memory, which includes Oracle's System Global Area (SGA). Because Oracle uses its own cache, using AIX file caching for this purpose only causes confusion, so we want to stop it. In this scenario, if you were to reduce maxperm, you'd be making the mistake of stopping the application caching programs that are running. You'd also be permitting lrud, the kernel process responsible for stealing memory when required, to do more work than necessary.

You should always be tracking your numperm, something you can do using nmon or topas or from the command line using vmstat (with the –v flag). If you leave the lru_file_repage default of 1, VMM will continue to use the computational and noncomputational repage counts (defined at the top) in determining whether to steal computational or file memory.

Here are the recommendations for configuring the other parameters we've discussed:

vmo -p -o minperm%=5

vmo –p –o maxperm%=90

vmo –p –o maxclient%=90

In AIX 6.1, IBM has changed the default parameter values to reflect these common defaults, so you'll have less to do in that release. You should also leave strict_maxperm and strict_maxclient at their default numbers. We used to change these settings, but we don't need to anymore. Changing them to 1 (the old approach) places a hard limit on the amount of memory that can be used for persistent file cache. This is done by making the maxperm value the upper limit for the cache. These days, this step is unnecessary because changing lru_file_repage is a far more effective way of tuning because we prefer that AIX file caching not be used at all.

minfree and maxfree

Two other important vmo parameters worth noting here are minfree and maxfree. These values set the lower and upper limits of the free list, which keeps track of the real memory frames released:

• minfree—Specifies the minimum number of frames on the free list, at which point the VMM will start to steal pages to replenish
• maxfree—Specifies the number of frames on the free list at which page stealing is to stop

If the number of pages on your free list falls below the minfree value, the VMM starts to steal pages (just to add to the free list), which is not good. It will continue to do this until the free list contains at least the number of pages specified in the maxfree parameter.

While you want to keep your free list higher (because you don't want your processes to be killed if the minfree value is reached), you want the VMM to always get the page frames it needs from the free list. I remember when the defaults used to be 120, and if I hadn't raised the values, users would nag me, saying no memory was left on the system. You also don't want the system to experience excessive I/O because it's always stealing paging to expand the free list. The default values now depend on the physical memory of the system. maxfree equals the lesser of the number of memory pages divided by 128 or 128. These values are the sum of all memory pools. The maxfree value should also be greater than or equal to maxpgahead.

Editor's note: This article is an excerpt from the book Driving the Power of AIX.