How do you troubleshoot performance problems on Linux?

Start by figuring out what the system is waiting on, rather than changing settings right away. Check uptime for load average, then use top or htop to see which processes are busy. Learn how to sort top by CPU and memory and how to read its output.

Next, try free -h, vmstat 1, iostat -xz 1, and df -h. Those give you a starting view of memory, system activity, disk behavior, and available space. Check journalctl and dmesg for errors around the time of the slowdown. Compare readings while the problem is happening with readings when things feel normal.

If the machine looks healthy, follow the delay outward. The application itself, network latency, DNS, a database, or another external dependency could be involved.

Get a baseline before chasing every high number. Record what CPU, memory, disk activity, and disk space normally look like under the workload you care about. A sudden change is often more useful than a snapshot taken in isolation.

For example, high memory use alone doesn't necessarily mean trouble. Linux uses memory for caching, so check what's available and whether the system is under memory pressure before assuming it needs more RAM. Atop can record metrics for later review if the slowdown is intermittent.

Low overall CPU usage can hide a bottleneck in one process or a delay outside the CPU. Once you've narrowed down where the time is going, use a profiler instead of guessing. perf is useful for CPU profiling, and async-profiler is another option for supported applications.

For a process that seems stuck waiting, strace can help show its system calls. For deeper system tracing, look into eBPF tools. These take more learning than top, so I'd use them after the basic checks give you a specific question to investigate.

Have a look at tuned-adm profiles if your system uses them. Reading what a profile changes can teach you about settings such as I/O scheduling and swappiness. But don't just switch profiles because the machine feels slow. First identify the bottleneck, then test any change against the same workload.