Edit: The alphaworks site is no longer live, although it does take you to an IBM site: https://developer.ibm.com/community/ I fondly remember lparmon, maybe it is time to bring it back.
Originally posted November 26, 2007 on AIXchange
In general, I find that customers and management more easily comprehend their system utilization when the data is displayed graphically rather than as text output. This is especially true when they want to see the overall performance and utilization of a machine that’s been carved into multiple LPARs.
I find it especially beneficial to show customers historical performance information plotted in a graphical format. The trends, spikes and utilization can be easier to identify when viewed graphically.
The Austin Executive Briefing Center has created a real-time graphical tool for use with System p.
IBM’s alphaWorks Web site has a description of the lparmon tool:
“LPAR Monitor for System p5 servers is a graphical logical partition (LPAR) monitoring tool that can be used to monitor the state of one or more LPARs on a System p5 server. LPAR state information that can be monitored with this tool includes LPAR entitlement/tracking, simultaneous multithreading (SMT) state, and processor and memory use. The LPARs to be monitored can be running any mixture of AIX 5.3, AIX 5.2, or the Linux operating systems.
“Included in Version 2.0 are several visual and functional enhancements, including the ability to group LPARs into user defined categories, set alert thresholds with associated alert actions, monitor and record into a file processor, and use memory data over time.
“The graphical LPAR tool consists of two components. First, there are small agents that run in AIX 5.3, AIX 5.2, or Linux LPARs on the p5 server. These agents gather various LPAR information through several operating-system commands and API calls. The agents then pass this information via a connected socket to the second component, which is the monitor’s graphical user interface. This graphical user interface is a Java application and it is used as a collection point for the server and LPAR status information, which it then displays in a graphical format for the user.”
Naturally, it’s easier to understand lparmon when you see it for yourself. Compare this output which was collected with lparmon:
To this output that I captured in a text window using topas:
I could have opened up xterm windows to all three of the LPARs that I was monitoring with lparmon. I could have run topas in each of them. But when you’re trying to show this information to people who might not be familiar with vmstat, topas or nmon output, it’s helpful to simply point them to lparmon’s easy-to-understand graphical dials rather than educate them on where they should be looking at the output. The lparmon output above is pretty clear in showing that host fifty2a is using most of the resources compared to the other LPARs.
Compare that to this third image when I put a load on my vio server:
Again, it’s easy to see what’s going on with the machine: vios1 is using available CPU capacity from the shared pool, above what it’s entitled to, as there are resources available for it to borrow from. When lparmon output is being shown live while making changes to a running machine, it can very clearly demonstrate the advantages of virtualizing your machine. And when setting up LPARs, you can see how different choices will impact your environment.
Furthermore, lparmon can be useful when monitoring production machines. You can see if LPARs have been set up with the correct number of virtual processors and if they’re using the shared CPU pool the way that you expect them to. I’ve seen instances where people thought they were using the shared pool, but hadn’t added enough virtual processors to allow the LPAR to do so. Thanks to lparmon, you can quickly see if your machine is overloaded, if you need to rebalance resources, etc.
So take the time to set it up and see how your machines are running. It’s worth adding lparmon to your collection of useful tools.