System Monitoring Commands

Load Average & Uptime

uptime
# 10:32:01 up 45 days,  2:14,  3 users,  load average: 1.25, 0.98, 0.75

The three numbers are load average over the last 1, 5, and 15 minutes — roughly, the average number of processes wanting CPU time. On an N-core machine, a load average near or above N means the system is CPU-saturated.

nproc                # number of CPU cores available

CPU & Process Overview: top / htop

top                  # live view: CPU%, memory%, per-process breakdown
top -o %CPU             # sort by CPU usage
htop                       # colorized, scrollable, more user-friendly (if installed)
mpstat 1 5                    # per-CPU-core utilization, 5 samples, 1 second apart

Memory: free

free -h
#               total        used        free      shared  buff/cache   available
# Mem:            15G        4.2G        1.1G        512M         10G         10G

available is the number that actually matters — it accounts for reclaimable page cache, unlike the raw “free” column which looks alarmingly low even on a healthy system.
High buff/cache is normal and healthy — Linux uses spare RAM to cache disk reads, and gives it back instantly when applications need it.

cat /proc/meminfo         # raw, detailed memory statistics straight from the kernel

Disk I/O: iostat

iostat -x 1 5             # extended stats, 5 samples, 1 second apart
# key columns: %util (device busy %), await (avg I/O wait time in ms), r/s and w/s (ops/sec)

A device consistently near 100% %util with rising await is I/O-bound — the classic sign is application latency with only modest CPU usage.

Virtual Memory: vmstat

vmstat 1 5
# key columns: r (runnable processes), b (blocked/waiting), si/so (swap in/out), us/sy/id/wa (CPU breakdown)

Non-zero, sustained si/so (swap activity) under load means the system is memory-constrained and actively swapping — a strong signal to investigate memory usage or add capacity.

Network Throughput

sar -n DEV 1 5             # network interface throughput over time (needs sysstat package)
ss -s                        # socket summary counts
nload                          # simple live in/out bandwidth graph (if installed)

All-in-One Snapshot

dstat                # combines CPU, disk, network, memory in one live view (if installed)

Reading the Signs: A Quick Decision Table

Symptom	Check	Likely Cause
High load, high CPU%	`top`, `mpstat`	CPU-bound workload
High load, low CPU%, processes in `D` state	`iostat`, `ps aux`	Disk/NFS I/O bound
`free` shows low available + swap activity	`free -h`, `vmstat`	Memory pressure
Slow app, network graphs spiking	`sar -n DEV`, `ss -i`	Network saturation or retransmits

Production Considerations

Never judge memory health from the raw “free” column alone — always check available, which accounts for reclaimable cache.
Sustained %util near 100% on iostat for a disk backing a database is a strong signal to look at storage type/IOPS limits (especially on cloud EBS/managed disks with provisioned IOPS caps).
Combine uptime’s load average with nproc — a load of 8 means very different things on a 4-core vs. a 32-core box.

Quick Interview Answer

“top/htop give a live per-process CPU/memory view, free -h shows memory with ‘available’ being the number that actually matters, iostat -x reveals disk I/O bottlenecks via %util and await, and vmstat shows swap activity and the CPU time breakdown between user/system/idle/wait. Load average from uptime needs to be read relative to core count (nproc) to mean anything.”

Common Mistakes

Panicking over a low “free” memory number in free -h without checking “available,” which is usually much higher and healthy.
Diagnosing high load purely as a CPU problem without checking process state — many high-load incidents are actually disk/NFS I/O wait (D state).
Comparing load average across machines without normalizing for core count.