Operations 19 min read

Diagnose Linux Server Performance in 60 Seconds with 10 Essential Commands

This guide walks you through ten Linux commands—such as uptime, dmesg, vmstat, mpstat, pidstat, iostat, free, sar, and top—to quickly assess CPU, memory, disk I/O, and network health, applying Brendan Gregg's USE method for pinpointing performance bottlenecks.

Liangxu Linux
Liangxu Linux
Liangxu Linux
Diagnose Linux Server Performance in 60 Seconds with 10 Essential Commands

This article presents a concise, 60‑second workflow for diagnosing Linux server performance issues using ten core commands, inspired by Netflix's performance engineering blog and Brendan Gregg's USE method.

Original source: https://tinyurl.com/rsyjhzhw
Netflix performance analysis blog: https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55
The USE Method: https://www.brendangregg.com/usemethod.html

The following commands, when run sequentially, give a high‑level view of system resource usage and help locate errors, saturation, and utilization metrics.

uptime
 dmesg | tail
 vmstat 1
 mpstat -P ALL 1
 pidstat 1
 iostat -xz 1
 free -m
 sar -n DEV 1
 sar -n TCP,ETCP 1
 top

1 uptime

Shows the system load averages for the past 1, 5, and 15 minutes. High 1‑minute load relative to the 15‑minute average indicates a recent spike that warrants deeper investigation.

Load average reflects the average number of runnable and uninterruptible processes.

Compare the three values to determine whether the load is transient or sustained.

Example output shows a 1‑minute load of 30.02, far above the 15‑minute average, prompting further checks.

2 dmesg | tail

Displays the last ten kernel messages. Look for OOM killer events, driver errors, or network drops that could explain performance degradation.

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: ...
[1880957.563408] Killed process 18694 (perl) ...
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request.

3 vmstat

Provides per‑second snapshots of CPU, memory, swap, and I/O statistics. Key columns for performance tuning include:

r : runnable processes (higher than CPU cores indicates CPU saturation).

free : available memory in kilobytes.

si/so : swap I/O activity (non‑zero values mean memory pressure).

us, sy, id, wa, st : CPU time distribution (user, system, idle, I/O wait, stolen).

4 mpstat -P ALL 1

Shows per‑CPU utilization each second. A single CPU with unusually high usage may point to a single‑threaded workload.

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
...

5 pidstat 1

Reports CPU usage per process every second, allowing you to spot processes that consume disproportionate CPU cycles.

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
...

6 iostat -xz 1

Monitors disk I/O statistics. Important fields include:

r/s, w/s, rkB/s, wkB/s : read/write operations and throughput.

await : average I/O wait time (high values suggest disk bottlenecks).

avgqu‑sz : average queue length (values > 1 indicate saturation).

%util : device utilization; > 60 % may impact performance, 100 % means full saturation.

7 free -m

Displays memory usage in megabytes. The "-/+ buffers/cache" line shows memory actually available to applications, as Linux uses free RAM for caching.

$ free -m
              total   used   free  shared buffers cached
Mem:        245998  24545 221453     83     59   541
-/+ buffers/cache: 23944 222053
Swap:            0      0      0

8 sar -n DEV 1

Shows network interface throughput per second, helping determine whether the NIC is saturated.

$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE   rxpck/s txpck/s rxkB/s txkB/s ...
12:16:49 AM eth0   18763.00 5032.00 20686.42 478.30 ...

9 sar -n TCP,ETCP 1

Provides TCP connection statistics, including active connections, passive connections, and retransmissions, useful for spotting network‑related performance issues.

$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s ise…
12:17:20 AM 1.00 0.00 10233.00 18846.00

10 top

Combines many of the above metrics in a real‑time, sortable view. It shows load average, per‑process CPU and memory usage, and can be paused to capture a snapshot for later analysis.

$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 2.7 id, 0.1 wa, ...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 ... java

By running these commands in sequence, you can quickly identify whether high CPU usage, memory pressure, I/O saturation, or network bottlenecks are responsible for observed performance problems. In the example output, two Java processes consume roughly 1600 % CPU, indicating that application‑level tuning is the next step.

These tools form a practical toolbox for Linux system administrators to perform rapid, data‑driven performance investigations.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

LinuxUSE method
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.