Linux Performance Commands: Finding Bottlenecks

When a game server stutters, a web app crawls, or a VPS suddenly stops responding, your first job is to answer the "why" with numbers. The right Linux performance commands exist for exactly this: instead of guessing, they show you within seconds whether the bottleneck lives in the CPU, memory, disk, or network. In this article I walk through the quartet of top, htop, iostat, and vmstat using real scenarios, and explain how to read the numbers they produce.

Start with load average: top

top ships with virtually every distribution, so it is the first place to look. The load average line at the top reports the number of runnable tasks over the last 1, 5, and 15 minutes. The practical rule: divide that value by your core count. Find the core count with nproc; on a 4-core machine, a load of 4 means roughly 100% utilization.

nproc            # number of cores
uptime           # just the load average line
top              # interactive monitoring

Inside top, reading the fields on the CPU line narrows the bottleneck down: us is CPU spent in user applications, sy is kernel (system) CPU, and wa is disk/IO wait. A high wa means "the CPU is idle but waiting on disk" and sends you straight to the storage side. The P key sorts processes by CPU and M by memory, so you instantly see which process is eating the most of a given resource.

A more readable view: htop

htop is the colourful, mouse-friendly modern take on top. It is rarely installed by default; add it with apt install htop or dnf install htop. The bars at the top show each core separately, which reveals cases where a single core is saturated (typical of single-threaded processes).

• F6 changes the sort column so you can bring the most expensive process to the front.
• F4 filters to show only the process you care about (for example mysqld or your game-server binary).
• F5 tree view clarifies which parent process spawned which children.

In the memory bar, green is used RAM and yellow is buffers/cache. It is completely normal for Linux to dedicate free RAM to cache; before panicking that "RAM is full", confirm the real bottleneck by looking at swap usage. If swap keeps climbing, memory really is insufficient.

For disk bottlenecks: iostat

If you saw a high wa, iostat is next. The tool comes in the sysstat package (apt install sysstat). You get meaningful data through interval sampling, not a single snapshot:

iostat -x 2      # extended stats every 2 seconds

The critical columns are: %util, the percentage of time the disk was busy; if it sits above 90% consistently, the disk is saturated. await is the average time an I/O request takes to complete (ms); expect single digits on an SSD and tens of ms on a spinning disk, so values far above that are a warning sign. r/s and w/s give the number of read/write operations per second. Ignore the first line because it is the average since boot; look at the second line and beyond.

On a database server, high await and %util mean either your queries are hammering the disk needlessly, or RAM is too small so the system keeps going to disk. The fix is usually not a faster disk but indexing your queries or adding memory.

For the whole picture: vmstat

vmstat summarizes CPU, memory, swap, and I/O on a single line, which makes it ideal as a "first diagnosis" tool. Run it on an interval too:

vmstat 2         # summary every 2 seconds

The fields to read: the r column is the number of processes ready to run but waiting on the CPU; if it stays above your core count, you have a CPU bottleneck. b counts processes in uninterruptible sleep (usually waiting on I/O). si/so are the memory swapped in/out per second; non-zero, sustained values are firm proof of memory pressure. wa is again I/O wait. Finally, if cs (context switches) and in (interrupts) are very high, you may have a workload that creates excessive context switching (for example thousands of short-lived processes).

A practical diagnostic flow

The most efficient approach is to use these tools as a flow rather than one by one:

• Step 1: Use top or htop to check the load average and which process stands out.
• Step 2: Decide whether the CPU is full or wa is high. If CPU, profile the process; if wa, move to disk.
• Step 3: Use iostat -x 2 to confirm whether the disk is saturated (%util, await).
• Step 4: Use vmstat 2 to check swap (si/so) usage and clarify whether there is memory pressure.
• Step 5: If you suspect the network, check the connection count and listening process with ss -s and ss -tnp.

These five steps turn a vague complaint like "the server is slow" into a concrete finding such as "MySQL is saturating the disk" or "a single core is pinned" within minutes. For continuous monitoring you can graduate to tools like Netdata or Prometheus that build on these very commands; but knowing how to read the manual commands first also makes the dashboard graphs far easier to interpret.

Frequently Asked Questions

Should I use top or htop?

Both show the same underlying data. top is reliable in emergencies because it is always present; htop is more readable, navigable with the mouse, and makes tasks like killing or filtering processes easier. For daily use I recommend installing htop but still knowing how to read top.

What load average should worry me?

There is no single threshold; divide the value by your core count. On a 4-core system, around 4 is fully loaded and 8 is twice the load. But to tell whether the load comes from the CPU or from I/O wait, always check the wa value as well.

Why does iostat's first line look different?

The first line is the average accumulated since boot and does not reflect the current state. To see real behaviour, run it on an interval like iostat -x 2 and read from the second line onward.

Is your server struggling with bottlenecks? We can diagnose your game server, VPS, or database performance together and turn it into a lasting fix. Get in touch and let's speed your server up.