Skip to content 
sar sysstat It provides me with historical metrics from Linux servers, which I use to accurately track load patterns, bottlenecks, and unusual behavior over time. This allows me to analyze CPU, RAM, I/O, and network usage retrospectively and identify recurring spikes that a live-only tool might easily overlook.
Key points
I will summarize the following key points briefly and clearly.
- History Instead of a snapshot: Regular monitoring reveals load patterns.
- Combination From collection and analysis: sysstat collects the data, and sar processes it.
- Width Metrics: CPU, RAM, swap, disk I/O, network, and more.
- Diagnosis Causes: Adjust time windows specifically and compare them.
- Planning Using trends: Realistically sizing capacity.
What do sar and sysstat do in everyday use?
I use sar as a system activity reporter that makes the data stored by sysstat readable. sysstat regularly collects CPU, memory, I/O, and network metrics, while I use sar to retrieve specific reports for particular time periods. This allows me to identify recurring load spikes caused by backups, cron jobs, or traffic peaks without having to guess. Unlike Live Tools Unlike top or htop, I don't just evaluate the current state; I also take into account how it has changed over time. This approach helps avoid misdiagnoses because it distinguishes between cause and effect and provides me with reliable insights.
Installation and Activation on Common Distributions
I install sysstat Using the package manager, enable logging and check the systemd timers. On Debian/Ubuntu, it's usually enough to apt install sysstat and a look at /etc/default/sysstatfollowed by systemctl enable --now sysstat. On RHEL/CentOS/Oracle Linux, I use dnf install sysstat and control the timers via systemctl. After that, daily files are usually saved in /var/log/sa/ with names like sa10 for the 10th of the month. I verify the entry with sar without parameters or with sar -u 1 3 for a quick ad hoc check.
An Explanation of the Most Important sar Commands
For the CPU, I use sar -u and, if necessary, per core sar -u -P ALLin order to Tips It's hard to miss. I view memory and caching as sar -r and swapping with sar -S. I read the disk activity using sar -d, the network with sar -n DEV,ETCP,TCP,UDP. I open historical files using sar -f /var/log/sa/sa10 and define a time window with -s HH:MM -e HH:MM . For detailed analyses of wait times, I'll supplement sar with Analyzing I/O Waits, because that way I can better evaluate queues and throughput, and Bottlenecks clearly identify.
Interpreting Metrics Correctly: CPU, Memory, I/O, Network
I look at a few key metrics that quickly give me a reliable picture and that I compare over time. CPU-Idle Values close to 0 and high %iowait values indicate queues on the disk. A high %steal value indicates CPU contention in virtualization. For RAM, I monitor free memory pages, page cache behavior, and swap-ins/swap-outs. For the network, packet errors, drops, and retransmissions help identify capacity limits or disruptions.
| Metrics | sar switch | Unusual Values | immediate action |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle very low, %iowait high | Check I/O, distribute threads, validate CPU requirements |
| Memory | sar -r | Low free space, significant page cache loss | Optimize services, expand RAM, evaluate caching |
| Swap | sar -S | Frequent swap-ins/swap-outs | Free Up RAM, Adjust Limits |
| Disk I/O | sar -d | High await/svctm values; queue is growing | Check the I/O profile, adjust storage tiering, or modify the batch window |
| Network | sar -n DEV,ETCP | Drops, Errors, Retransmissions | Test MTU/Offloading; Analyze Bandwidth and Latency |
Analyze Historical Data and Time Frames
I almost always work with Time Windows, for example sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 for night shifts. This way, I compare the same time periods on different days and identify trends rather than isolated incidents. For automated analysis, I save data with sadf -d in CSV format and upload them to my own dashboard. When I see unusual spikes, I look at adjacent intervals to rule out side effects. I keep this method streamlined because it gives me actionable insights quickly, without requiring a lot of preliminary work.
Trend Analysis and Capacity Planning
I use the archived values for Forecasts and I size resources based on actual data rather than gut feeling. If CPU utilization increases on a weekly basis, I plan for additional cores or clock speed headroom. If memory requirements grow due to caches, I weigh the benefits against adding more RAM. If the I/O path shows increased wait times, I decide whether to use faster storage or decoupled batch windows. For visualization, I alternatively link data to Grafana and Prometheus and combine SAR trends with metrics from exporters.
Real-World Example: Web Server with Peak Loads
I'll outline a scenario in which WordPress sites respond slowly every evening and Users Report abortions. With sar -u -s 18:00:00 -e 20:00:00 and sar -d I notice simultaneous I/O spikes during backups. At the same time, it shows sar -n DEV increasing network throughput, which rounds out the load situation. A cross-check the following day—without the backup—confirms the pattern. I reschedule the job, optimize database queries, and flush the caches, which eliminates the evening spikes and restores consistent response times.
Tips for Data Management, Rotation, and Retention
I check the Storage in /etc/sysconfig/sysstat or /etc/default/sysstat and adjust the retention period as needed. For critical hosts, I retain data for 30–90 days to identify seasonal trends. The file size remains manageable as long as the intervals are reasonable and there is no excessive second-by-second logging. I rotate older archives to a central directory or move them to a simple long-term storage solution. This way, I keep data available without overloading the system or slowing down analysis.
Integration with Monitoring Stacks and Logs
I set sar to Raw data-I integrate a supplier's data and combine it with centralized monitoring, log analysis, and alerting. An APM or log stack provides me with events, while `sar` timestamps the infrastructure metrics. For particularly noisy hosts, I also use pidstat and iostat, to map processes and I/O paths. In addition, this helps me Process Accounting, to accurately identify resource-intensive processes. This combination of event and metric views prevents me from flying blind and significantly shortens my troubleshooting time.
Fine-tuning the configuration: Intervals, sa1/sa2, and Timer
I put the Sampling Intervals set them so that they match the system's dynamics. A one-minute interval is a good standard, while for highly volatile hosts, intervals of 10–30 seconds may also be appropriate. The collection handles sa1 (frequent samples), the daily summary sa2 (Reports for the day). Under systemd, I check the relevant timers or services and adjust the frequency. On Debian/Ubuntu, I often explicitly enable data collection with ENABLED="true" in /etc/default/sysstat. I document the intervals for each environment so that later comparisons are accurate and no one draws incorrect conclusions from 5-second samples compared to 1-minute data.
An Overview of Advanced sar Options
In addition to the standard controls, extra switches help me with a Full View: sar -b shows aggregated block I/O throughput, sar -B the kernel's paging behavior and sar -W Swap activity in detail. With sar -q I can see the runqueue (processes waiting for the CPU) and the load trend. sar -H provides Hugepage data when relevant. For disks, I use it when necessary sar -d -p, to view partitions separately. I'm cautious about svctm: This value is sometimes unreliable or 0 in modern kernels; I prefer to await (end-to-end latency) and avgqu-sz/aqu-sz (queue size). And when I need a quick overview, it provides sar -A a broad overview, which I then narrow down.
Properly Evaluating Virtual Machines and Containers
At Virtualization I pay particular attention to %steal: High steal values mean that the VM’s hypervisor is taking CPU time away from the VM. This can easily lead to misjudgments if I only evaluate %idle. I therefore correlate CPU utilization, steal, and runqueue (sar -q) together. In container environments, I separate the host and workload views: sar monitors the host, not individual containers. If I need details for each service, I supplement this with pidstat (per process) and take cgroups limits into account. I also check CPU frequency scaling and power states (clock speed changes), because they can cause short-term latency that, out of context, may appear to be CPU starvation.
Time Reference: Time Zones, Daylight Saving Time, and Reliable Correlation
I pay attention to constant time base, so that comparisons are accurate. By default, sar saves data in local time; for clusters, it’s a good idea to use a uniform time zone (often UTC). Around the time of the daylight saving time change, I check for duplicate or missing time slots and, if necessary, use the output from sadf with timestamps in ISO format. When correlating with logs or APM events, I adjust for time zones to precisely match peaks in metrics with specific events (deployments, backups, cron jobs). Accurate time references significantly reduce misunderstandings in incident postmortems.
Automate and Export with sadf
For reports and dashboards, I export data using sadf. In my daily life, I use sadf -d (CSV) for simple analyses, or alternatively sadf -j (JSON) for flexible pipelines. A typical export looks like this: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_evening.csv. This is how I generate a file containing CPU, RAM, block I/O, and network metrics for an evening time window. In scripts, I use this data to automatically compare weekdays, calculate the median and 95th percentile, and flag outliers. I deliberately keep the set of metrics lean to maintain readability and avoid false positives.
Case Study: Database Server with Page Cache Pressure
A MySQL host is experiencing sporadic query latency. sar -r shows a decrease in the page cache in the evening, sar -S occasional swap-outs. At the same time, there is a growing trend at sar -d the await-time, and sar -b indicates increased write traffic. The correlation with log rotations and an ETL job explains the pattern: Large sequential write bursts flush the cache and push database reads into I/O. I stagger the jobs, moderately increase RAM, and specifically set the DB buffer to a larger size. Afterward, the await and swap values remain stable, latencies decrease, and the page cache reliably keeps the hot sets in memory.
Operational Aspects: Overhead, Device Lists, and Filters
I hold the Overhead small by selecting a representative sample. Sysstat primarily reads from /proc and writes in binary; with minute-long intervals, I hardly notice the load. On hosts with a large number of devices or short-lived block devices (e.g., during snapshots), I filter the output specifically and evaluate only relevant paths. For dm-crypt, MD-RAID, or multipath devices, I check both the logical device and—where possible—the underlying device to correctly identify bottlenecks. I document the device names so that later comparisons aren’t hindered by renamed paths.
Methodology: Baselines and Comparison Days
For each host, I define a Baseline per time window (e.g., 1:00–5:00 a.m. batch, 9:00 a.m.–6:00 p.m. office, 6:00–10:00 p.m. peak). For each window, I note typical median values and acceptable percentiles (e.g., CPU-%idle, await, avgqu-sz, retransmissions). If I notice any deviations, I first look for new jobs, deployments, or traffic patterns—only then do I consider capacity expansions. This disciplined approach prevents hasty decisions: Often, a small change in planning or an adjustment to limits solves the problem better than expensive hardware upgrades. sar provides me with a reliable factual basis for this over weeks and months.
Limits and useful additions
I don't see sar as a replacement for Alerting, because by default it doesn’t monitor thresholds or send notifications. Real-time alerts belong in dedicated systems that map out rules, escalations, and team workflows. I also cover deep metrics for applications, databases, or JVMs using exporters and tracing. sar shines when I want to compare system resources over time and identify operational bottlenecks. Overall, I use it specifically when I need quick, repeatable answers to infrastructure-related questions.
Briefly summarized
I use sar and sysstat to turn metrics into a clear history of server load. The combination of regular data collection and targeted analysis helps identify root causes rather than just guessing at symptoms. With just a few commands, I can uncover CPU, memory, I/O, and network issues and pinpoint when they occurred. From this, I derive realistic capacity decisions and identify inefficient routines, such as poorly timed backups. Those responsible for Linux servers will find this method provides reliable guidance and saves time during analysis, planning, and operations.
