Unix tip: Using sar for long-term performance analysis
The sar command, native to Solaris and often installed on Linux systems via the sysstat package, is extremely useful in analyzing current and recent system performance. On the other hand, if you would like to view performance on your servers over a long time span (more than a month), you need to take some extra steps to preserve your data.
Since I am both a sysadmin and a climate activist, I am concerned about the power being used by idle servers. And I'm not alone. At the Green Computing Summit that I attended in Washington, DC a little over a week ago, representatives from a number of federal agencies and many energy-conscious companies discussed their concern for both the cost and climatic repercussions of energy wasted on idle systems.
Given these concerns, I have been keeping data on CPU usage for a large collection of servers over a long span of time. These statistics give me an good idea which servers are seriously underused and might be shut down either completely or when not in use and those which I can justify running 7x24.
The first step in this long-term performance data collection is running sar normally on all the servers that I want to monitor. In the default setup, sar collects data during normal business hours and generates a report in the evening (Monday through Friday). Since my interest in long-term analysis was limited to keeping track of CPU usage, I collected only a small portion of each daily report to generate monthly averages.
The script shown below assumes that the sar* (report) files have been gathered in /perf/data/ directories. File dates are preserved during the transfer and files more than one month old are removed to keep the directories current and avoid having to question whether a file named sar06, for example, represents system performance on May 6th or June 6th.
Invoked directly, this script prepares a monthly report on a single server. The report will include the average CPU usage line from the sar report for each of the sar reports created in the prior 30 days. Notice that the report below skips weekends (when performance statistics are not collected).
# ./showUsage boson boson: %usr %sys %wio %idle Apr 30 15 5 1 78 May 1 15 5 1 79 May 2 16 5 1 78 May 5 15 5 1 78 May 6 15 6 4 75 May 7 15 5 1 79 May 8 15 5 1 79 May 9 16 7 2 76 ... truncated ... May 29 15 6 1 75 Average 15 5 1 74
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
On Twitter now
solaris
Powered by Twitter
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Where Google Chrome security fails: the password
I heard mention that the Chrome OS will have some sort of encryption available a la bitlocker. If it's possible to encrypt personal data using another password or key, then it may have potential for very secure data.... And Ubuntu has an 'encrypt home directory' option, perhaps google should follow suit.
- Dann
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.













