How to Diagnose Linux Server Performance with iostat, free, sar, and top

The article continues a previous tutorial on quickly checking Linux server performance and focuses on four essential commands: iostat , free , sar , and top . Each command’s output is shown with sample data and the meaning of critical columns is explained.

iostat -xz 1

The iostat -xz 1 command displays extended disk I/O statistics every second. Important columns include: r/s, w/s, rkB/s, wkB/s: read/write operations per second and data transferred in kilobytes. await: average I/O wait time in milliseconds; high values indicate possible hardware bottlenecks. avgqu-sz: average queue length; values greater than 1 suggest the device is saturated. %util: device utilization percentage; values above 60% may affect performance, and 100% means full saturation.

Logical devices may show high utilization without indicating physical saturation, and strategies like read-ahead and write caching can improve performance.

free -m

The

free -m</b> command reports memory usage in megabytes. The second line (‑/+ buffers/cache) separates memory used by applications from memory used for buffers and cache. Linux tends to use free memory for caching, which is reclaimed when applications need it, so the cached memory is effectively available.</p>
<p>If available memory becomes scarce, the system may start swapping, increasing I/O overhead and degrading performance.</p>
<h2>sar -n DEV 1</h2>
<p>The <code>sar -n DEV 1

command monitors network device throughput. It shows packets and kilobytes per second for each interface. By examining these values, you can determine whether a network interface is saturated; for example, an eth0 interface showing around 22 MB/s (≈176 Mbit/s) is well below a 1 Gbit/s limit.

sar -n TCP,ETCP 1

The sar -n TCP,ETCP 1 command provides TCP connection statistics, including: active/s: connections initiated locally per second. passive/s: connections accepted from remote hosts per second. retrans/s: TCP retransmissions per second, indicating possible network issues or server overload.

These metrics help identify whether performance problems stem from excessive connection attempts or network instability.

top

The top command offers a real‑time snapshot of system load, CPU usage, memory consumption, and active processes. It aggregates information from commands like uptime, free, and vmstat. While useful for quick inspection, its output is instantaneous; pausing the refresh can help capture and compare data over time.

Conclusion

Combining these tools enables rapid identification of performance issues on Linux servers. In the provided example, a Java process consumes a large share of CPU, suggesting that subsequent tuning should focus on the application.