AIX > Administrator > Performance

Avoiding Issues Using the 2012 AIX Performance Update

So what changes do I make in the starter set? The network parameters always need changing because the defaults are rarely correct. Do so using the no command to set the defaults as well as the chdev command to set the individual network adapters (use ifconfig –a to compare). The red parameters in Table 1 are the new defaults and the system should be allowed to default to these.

Finally, let’s look at performance issues. First, it’s helpful to understand the process involved in opening a PMR for a performance problem. IBM’s perfpmr website not only provides this tool, but also a link that discusses how to report performance problems. Whenever a performance problem occurs, IBM will request you run the perfpmr script, which collects performance data necessary to analyze the problem. I recommend getting familiar with running the tool before an emergency situation arises. However, you should always download the latest version when experiencing an actual problem as it’s updated regularly.

Understand that performance tuning is an iterative process—it doesn’t happen overnight. Even if all of the aforementioned recommendations have been followed, a quick fix might not be available when an issue arises—some problems take minutes to fix, others take months. So it’s important to have a plan.

The first thing I recommend is to keep a baseline. Pick a tool (I like nmon and perfpmr.) and save a baseline of the system on a typical day when it’s healthy. Whenever you make system changes, create a new baseline before and after so you have performance points for comparison. When you suspect a problem, rerun the baseline to see if anything is obvious to you. Without a baseline, you have nothing to compare your problem to, which makes resolution challenging. And, of course, good change control and documentation are critical.

The next step is to have a plan. Typically, it will look like this:

  1. Describe the problem.
  2. Measure where you’re at (baseline).
  3. Recreate the problem while getting diagnostic data (perfpmr, your own scripts, etc.).
  4. Analyze the data.
  5. Document potential changes and their expected impact, then group and prioritize them.
  6. Make the changes.
  7. Measure the results and analyze if they had the expected impact; if not, then why not?
  8. Is the problem still the same? If not, return to step 1.
  9. If it’s the same, return to step 3.

This all sounds like common sense but, in an emergency, many of these steps get missed or rushed through. It’s important to document and analyze the changes, especially if you end up in a PMR situation. One small change that only you know about can cause significant problems.

It’s also beneficial to group changes into sets and to make them one set at a time. Alternatively, if you make 50 changes at a time, you’ll never know which one fixed the problem. While many companies have limited maintenance windows, pushing through changes to everything in the infrastructure in one window is a recipe for disaster. Wherever possible, try to get more (but shorter) maintenance windows and use techniques like alternate disk install that will allow fast recovery if you need to go back after a change.

By putting into place the best practices outlined here you should be able to avoid most problems. And by following these steps when you do encounter an issue, the problem-resolution process should be less painful, especially if you gather good baselines for comparison. This will help IBM (and you) immensely, particularly if you build perfpmr into your baseline. Hopefully, you won’t encounter performance issues, but if you do, these practices should help make the resolution process easier.

Starter Set of Tunables

NETWORK (no)        
rfc1323 0 0 0 1
tcp_sendspace 16384 16384 16384 262144 (1Gb)
tcp_recvspace 16384 16384 16384 262144 (1Gb)
udp_sendspace 9216 9216 9216 65536
udp_recvspace 42080 42080 42080 655360
MEMORY (vmo)        
minperm% 20 3 3 3
maxperm% 80 90 90 90
JFS, NFS, VxFS, JFS2        
maxclient% 80 90 90 90
JFS2, NFS        
lru_file_repage 1 0 0 0
lru_poll_interval ? 10 10 10
Minfree 960 960 960 calculation
Maxfree 1088 1088 1088 calculation
page_steal_method 0 0/1 (TL) 1 1
JFS2 (ioo)        
j2_dynamicBufferPreallocation 16 16 16 as needed

Jaqui Lynch is an independent consultant, focusing on enterprise architecture, performance and delivery on Power Systems with AIX and Linux.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Achieving a Resilient Data Center

Implement these techniques to improve data-center resiliency.


AIO: The Fast Path to Great Performance

AIX Enhancements -- Workload Partitioning

The most exciting POWER6 enhancement, live partition mobility, allows one to migrate a running LPAR to another physical box and is designed to move running partitions from one POWER6 processor-based server to another without any application downtime whatsoever.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters