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
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
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.












