IBM Power Systems have the ability to run both the IBM i and AIX (as well as Linux) operating systems, so how can you leverage your existing IBM i performance analysis skills to provide AIX support?
Every system, from Charles Babbage’s first mechanical computers in the early nineteenth century to the high-end Power Systems we see today, regardless of operating system, have the same three fundamental components: input, process, and output.
Whether it’s punched cards and paper tape or data entry clerks and EDI file transfers, with input comes queues and with queues comes queueing. The length of the queues depends on how quickly the processing can deal with the current requests.
Many elements can impact process, but the most influential are the speed of the processor(s) and the amount of memory assigned to the server. Work management techniques offer many ways to control where specific pieces of work get processed and when they get paged out to memory.
Once the processor has completed a piece of work, the results require a form of output, often to a display station, file, or printer.
The only change across these three components between each flavor of operating system are the commands and utilities available to the system administrator for tracking, controlling, and reporting on the underlying performance of your server.
Listed below are AIX parallels to IBM i features. These are aimed at administrators tasked with ongoing performance management and analysis of AIX, but are more familiar with IBM i concepts.
IBM i has job queues that, via subsystem job queue entries, feed into pools of memory that help administrators control jobs and the order in which they’re processed. Additionally, IBM i ships with a basic job scheduler.
Each CPU (central processing unit) on an AIX server has its own personal run queue, in addition to the server as a whole, which maintains the global run queue. AIX ships with a scheduler called cron, which offers more flexibility than the IBM i equivalent. For example, you’re able to run jobs (commands or scripts) at specific dates, days, and times, and also periodically at user-defined intervals.
The at command can be used to submit a job to run once at a specific date and time in the future. The same command can also be used to schedule a job relative to the current time, for example 12 hours from now.
Use the atq command to view a list of all jobs scheduled.
AIX also provides a neat batch command that will automatically process your job when the system has its next quiet period. This period is denoted by when the system load average figures (which can be obtained manually using the uptime command) are less than 1.5 (the number of processes that are queued, including the processes that are currently being executed).
There is an AIX concept called processor affinity, which allows administrators to control which processor handles which specific processes and threads.
On IBM i, overall CPU activity is visible by using commands such as WRKSYSACT, WRKACTJOB, or WRKSYSSTS. On occasions when using shared processors in an uncapped partition configuration, you might see CPU figures in excess of 100 percent. In this respect, AIX is identical.
The topas command provides real-time interval information (defaulted to 2 seconds) on items such as CPU, disk utilization, process, paging, memory, and network adapter utilization figures. The left-hand side of the screen presents you with the ability to part-customize what you see by way of using toggle keys. To learn about these use the <h> key to access the help menu.
On IBM i, the speed at which jobs are processed depends on a number of factors, including run priority and time slice, which are traditionally maintained by the CHGJOB command on IBM i. Again just like IBM i, AIX provides the nice and renice commands to change the run priority of a job.
By default, AIX user jobs have a base priority level set to 40, plus a default nice value of 20. When added together, this forms the default priority level. The higher the default priority, the lower the actual priority the system gives to the job. To show the current priorities and nice values assigned to active processes use ps –efl and you’ll see the PRI (priority) and NI (nice) columns.
Another command schedo can also be used to adjust (up or down) the amount of time the operating system provides to a process before moving onto another process, potentially paging out the original request.
Collection Services is the standard in IBM i performance monitoring, and it comes built into the operating system. This function allows you to create database files for later analysis. The data can be managed and extracted from both IBM i green screen or within the web-based IBM Navigator for i.
AIX provides the topasout command, which stores data visible in topas for later analysis. Short for Nigel’s monitor, nmon or topas_nmon have been included in the AIX base operating system for some years now, despite not being officially supported by IBM. These are widely considered the de facto standard for AIX performance monitoring and analysis. They have two modes, real-time and data capture, with the former being excellent for both historical reporting and performance analysis purposes.
The best way to use the collected nmon data is via the nmon analyzer. The analyzer is an embedded Microsoft Excel spreadsheet macro that, when pointed to the collected nmon data streams, automatically generates dozens of template-based graphs.
These days, performance analysis and reporting often isn’t isolated to a single server flavor. For users of the IBM Hardware Management Console (HMC), there is a neat built-in feature. By checking the “allow performance information collection” box on the partition properties for your AIX (or IBM i or Linux) servers, you can view the data in the IBM Navigator for i, accessible via a browser on port 2001. For example: https://systemname:2001
You can drill into the data, display it in a graph or table, and even export into CSV for analysis in another third-party tool.