Linux Server Performance: Measure Before Tuning

Performance tuning is most useful after you identify a measurable bottleneck. A high CPU percentage, low free-memory number or large disk queue is a clue, not a diagnosis on its own. Compare the symptom with the service's normal workload and user-visible latency.

Establish a baseline

Record the time window, workload, request latency and resource metrics. Compare the affected period with a known healthy period. Check CPU saturation and run queue, memory pressure and swap activity, storage latency and network retransmissions. Use monitoring history where available; a one-time terminal snapshot cannot show when the problem began.

Trace the slow request

Identify which service or operation is slow and correlate its logs with system metrics. A database query, lock wait or remote dependency can make an application feel slow while the CPU is mostly idle. Likewise, a busy host may still serve the workload acceptably if latency remains within its target.

Change one variable at a time

Test a proposed change with representative traffic in staging or a controlled window. Record the previous value and define a rollback. CPU affinity, kernel parameters and cache sizes can make one workload faster while starving another or increasing memory pressure. Do not copy tuning values from a different server without matching hardware and workload.

Canonical's Ubuntu performance documentation emphasizes measuring behavior before applying tuning tools. The same principle applies across distributions: optimize the bottleneck you observed and confirm that the change improved the service, not merely a dashboard number.

Keep the measurement and result with the change record. That makes later capacity planning and rollback decisions much more grounded.