Linux performance tools: choose the measurement before changing the system

Linux performance work starts with a question: which resource or part of the request path is limiting the service? Tools are most useful when they test a hypothesis rather than produce a dashboard of unexplained numbers.

CPU and system load

Use tools such as uptime, top, htop, mpstat or pidstat to investigate load, CPU use and process behavior. Load average is not the same as CPU utilization: waiting tasks and the number of available CPUs affect interpretation.

Memory

Use free and vmstat to examine memory and paging activity. Read the values in the context of Linux caching and available memory. A low “free” value alone does not establish a memory shortage.

Storage and I/O

Use iostat and, where appropriate, process-level I/O tools to examine latency and activity. Connect the observations to the device and workload. A busy device metric needs context before it becomes a reason to buy faster storage.

Network

Use ss and appropriate traffic or packet-analysis tools to examine connections, retransmissions and throughput. Packet capture can include sensitive information; limit collection and access to the investigation’s needs.

Go deeper when the evidence calls for it

Profiling tools such as perf or eBPF-based tools can help explain application and kernel behavior, but availability, privileges and overhead vary. Check the installed system and test the collection approach before using it on a critical workload.

Brendan Gregg’s USE method provides a useful structure: examine utilization, saturation and errors for relevant resources. Record the baseline, time window and workload so later comparisons mean something.

For help connecting measurements to action, explore Linux engineering and ongoing operations.