Master Linux Performance Monitoring: Key Metrics & Tools Explained
This guide outlines essential Linux performance evaluation areas—CPU, memory, disk I/O, network I/O, and overall system load—detailing the primary commands (vmstat, free, iostat, ifstat, top), interpreting their output fields, and offering practical thresholds for diagnosing bottlenecks.
Key Performance Evaluation Areas
CPU – Main tool: vmstat Memory – Main tool: free Disk I/O – Main tools: iostat, sar Network I/O – Main tool: ifstat Overall System Performance – Main tool:
topCPU Evaluation
Key vmstat fields: r – number of processes running or waiting for CPU time slice. b – number of processes blocked for resources. si – kilobytes per second read from swap. so – kilobytes per second written to swap. us – user‑mode CPU usage. sy – system‑mode CPU usage. id – idle CPU percentage (us + sy + id = 100%).
Practical insights:
If procs:r consistently exceeds the number of CPU cores, the CPU is a bottleneck.
A high procs:b value indicates heavy system pressure.
Non‑zero swap:si suggests insufficient physical memory or a memory leak.
When cpu:us stays above 50% for a long period, consider optimizing the application.
Elevated cpu:sy often points to intensive I/O system calls.
If us + sy exceeds 80%, the CPU may be undersized.
Memory Evaluation
The free command shows available memory for applications.
Practical insights:
Free/Total > 70% → memory is abundant.
Free/Total < 20% → memory shortage.
20% < Free/Total < 70% → memory is generally sufficient.
Disk I/O Evaluation
Key iostat fields: rkB/s – kilobytes read per second. wkB/s – kilobytes written per second. svctm – average service time per I/O request (ms). await – average wait time per I/O request (ms); lower is better. util – percentage of time the device was busy; values near 100% indicate saturated bandwidth.
Practical insights:
Persistently high rkB/s and wkB/s indicate heavy read/write load.
If svctm and await are similar, I/O latency is low and performance is good.
When await far exceeds svctm, I/O queues are long and the system may need tuning or faster storage.
Network I/O Evaluation
Key ifstat fields: RX Pkts/Rate – incoming packet rate. RX Errs/Drop – packet loss. TX Pkts/Rate – outgoing packet rate. RX Data/Rate – incoming data volume. TX Data/Rate – outgoing data volume.
Overall System Performance Evaluation
The top command’s load average shows the average length of the run queue over 1, 5, and 15 minutes.
Practical insight: The three load values should generally not exceed the number of CPU cores; sustained values above the core count indicate a heavily loaded CPU.
For a system with 2 CPUs, a healthy threshold is load average < 2.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.