Edit: This is something I have not thought about in a long time.
Originally posted February 28, 2012 on AIXchange
I’ve touched on Active System Optimizer (ASO) before, but now that Nigel Griffiths has released an ASO video, it seems an appropriate time to expound on this topic.
To run ASO, you must be at AIX7.1 TL01 or greater on POWER7 hardware running in POWER7 mode. ASO is installed by default on AIX 7. It’s not supported on older AIX releases or older hardware. (It will appear to be running, but will actually be hibernating.)
Nigel recommends running:
* oslevel –s to verify your AIX version
* lslpp –L | grep –I optimi to help verify that the ASO fileset is installed
* lsconf | grep ^Processor to verify that your LPAR is running in POWER7 mode.
ASO works under the covers; you don’t need to do anything to start it. It optimizes workloads based on AIX kernel statistics and the POWER7 hardware performance counters. It’s designed to improve cache and memory affinity by dynamically evaluating tuning options and making changes — including moving processes and memory — on the fly. It conducts pre- and post-monitoring to ensure that the changes improve performance. If improvement isn’t detected, ASO backs out the changes, hibernates and tries again later. Listen to Nigel’s presentation for details on this.
ASO provides cache affinity, aggressive cache affinity and memory affinity. It monitors performance and detects situations where threads can be moved from one chip to another to utilize the closer L3 cache.
ASO operates best on multi-threaded workloads. The jobs it monitors should be stable and long-running so it can most effectively make changes to the workload. It also needs to be a busy LPAR, otherwise you don’t gain much by trying to move things around. By “busy,” I mean that the processes need at least a 10-second lifetime. If applications come and go more quickly, ASO cannot make recommendations. If you’ve done manual tuning, either on your own or based on recommendations from IBM Support, ASO will simply hibernate rather than monitor and override your changes. In addition, specific processes can be marked as “don’t bother these,” and ASO won’t impact them.
ASO runs as an SRC kernel service. To locate it, search your machine for the aso process.
Use these commands to get ASO running:
1) start the kernel service with startsrc –s aso
2) run asoo –o aso_active=1
According to Nigel, the aso process uses very minimal CPU time, so this shouldn’t add much additional overhead on the system.
Logs are located in the /var/log/aso/* directory. You’ll see two files:
* aso.log, which has on/off/hibernating information
* aso_process.log, which provides details of actions and modified processes
Nigel says this log file isn’t formally documented, but you should be able figure out what it’s doing.
The man page says ASO can run outside of SRC, but this should probably only be done for debugging. You can also set shell variables before starting processes and apps. This provides some control over how they function with ASO.
As always, Nigel has much more than I can cover here. For instance, he shows real life examples of ASO running on his machine, output from the logfile, and more.
To wrap up, he tells us that ASO is largely set and forget. ASO uses near zero CPU when running, and it gently applies changes, tests behavior and undoes the changes if necessary. Because ASO is good for complex, multithreaded, long-running applications, it can move things around inside of your LPAR if they’re spread across CPUs.
Best of all, this is, as he says, just the first phase of clever autonomic affinity tuning. So keep your eyes open for what’s ahead.