Performance troubleshooting becomes much easier when the investigation follows layers rather than jumping between random commands. Start with the user-visible symptom, establish a time window, then move through resource pressure and application behavior.
Start with the symptom
Write down what is actually slow: login, API response, batch processing, storage operation, database query or network transfer. "The server is slow" is not yet a measurable problem statement.
uptime
systemctl --failed
journalctl -p warning..alert --since "30 minutes ago"
CPU
High CPU usage can be healthy if useful work is being completed. Look for sustained run-queue pressure, a single runaway process, excessive system time or scheduler contention.
vmstat 1
pidstat -u 1
top
Memory
Do not interpret low free memory as a problem by itself. Linux deliberately uses spare memory for cache. Look instead for reclaim pressure, swapping, OOM activity and working-set behavior.
free -h
vmstat 1
journalctl -k | grep -i -E 'oom|out of memory'
Storage
Storage latency often appears as application slowness. Separate throughput from latency and queueing.
iostat -xz 1
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
Network
Confirm both connectivity and quality. Packet loss, retransmissions, DNS delays and connection saturation can all look like an application issue.
ss -s
ip -s link
ss -tan state established | head
Correlate before changing
A strong incident note records the symptom, time, affected workload, observed resource pressure, commands used, findings, changes and outcome. That record becomes future operational knowledge instead of disappearing after the incident.