htop/top di Linux: Panduan Lengkap Membaca Setiap Metrik Monitoring Server

Pertama kali manage VPS production, buka htop dan bingung. Kenapa load average tinggi tapi CPU usage rendah? Kenapa memory usage 90% tapi server masih cepat? Kenapa ada "wa" di CPU bar tapi gak keliatan proses yang bikin bottleneck?

Artikel ini bakal breakdown setiap baris dan kolom di htop/top, kenapa setiap metrik penting, dan gimana interpretasi yang benar untuk debugging server performance.

Header: System Overview

Baris pertama di htop menampilkan overview sistem. Gw breakdown satu per satu:

1  [|||||||   67.3%]   Tasks: 245, 380 thr; 2 running
2  [|||||||   62.1%]   Load average: 4.32 3.87 2.91
3  [|||||      55.2%]   Uptime: 45 days, 12:34:56
4  [||||       48.7%]
5  [|||        35.4%]   RAM: 7.2 GiB/15.6 GiB [|||||||||||||||| 46.1%]
6  [||         28.9%]   Swap: 2.1 GiB/8.0 GiB [|||||            26.2%]
7  [           12.3%]   Tasks: 245, 380 thr; 2 running
8  [            8.1%]

Load Average — Yang Paling Sering Salah Interpretasi

Load average: 4.32 3.87 2.91

Tiga angka ini adalah 1 menit, 5 menit, dan 15 menit rolling average dari jumlah proses yang sedang menunggu execution (running + waiting for CPU atau waiting for I/O).

Kesalahan umum: Load average 4 di server 4 core berarti server "100% utilized". Salah. Load average termasuk proses yang menunggu I/O (disk read/write, network). Jadi load 4 bisa berarti:

Scenario	Running	Waiting I/O	Severity
4 proses CPU-bound	4	0	High — CPU bottleneck
1 CPU + 3 I/O wait	1	3	Medium — I/O bottleneck
0 CPU + 4 I/O wait	0	4	Critical — Disk bottleneck

Cara bener: load average harus dibandingkan dengan jumlah CPU cores. Kalau load > cores secara konsisten, ada bottleneck.

CPU Bar Breakdown

Setiap bar di CPU mewakili satu core. Warna-warna di dalamnya:

Color	Meaning	Action Required
green	Normal user processes	No action
blue	Low priority (nice)	Check nice values
red	Kernel processes	Investigate — kernel busy
cyan	Hardware interrupts (hi)	Network bottleneck
magenta	Software interrupts (si)	Check softirq stats
yellow	I/O wait (wa)	Disk bottleneck — check iostat

Kalau lo lihat wa tinggi di CPU bar, itu artinya proses menunggu disk I/O. Bukan CPU yang bottleneck, tapi disk. Di VPS yang pakai HDD, ini sangat umum terjadi.

Proses Table: Kolom yang Sering Diabaikan

PRIORITY vs NICE

Dua kolom ini sering disalahartikan:

PRI (Priority): Internal kernel priority. Semua user processes biasanya di 0
NI (Nice): User-defined priority. Range -20 (highest) sampai 19 (lowest)

Cara ubah nice value:

# Jalankan proses dengan nice -10 (higher priority)
nice -n -10 ./my-application

# Ubah nice value proses yang sudah jalan
renice -n 5 -p $(pgrep my-application)

VIRT vs RES vs SHR — Memory

Ini kolom memory yang paling sering salah interpretasi:

Kolom	Meaning	Yang Sebenarnya
VIRT	Virtual Memory	Total memory yang di-allocate (termasuk yang belum dipake)
RES	Resident Memory	Memory yang benar-benar sedang dipakai
SHR	Shared Memory	Memory yang dipakai bersama (shared libraries)

Kesalahan umum: VIRT 2GB tapi RES 50MB. Lo panik, "kok memory gede banget?" Tenang — VIRT bukan berarti lo pakai 2GB. Itu cuma address space yang di-map. Yang penting lihat RES.

Kenapa VIRT bisa besar tapi RES kecil? Karena:

# Shared libraries di-map tapi belum di-access
# malloc() allocate tapi belum di-write
# mmap() file tapi belum di-read

S dan S+ State

Kolom S menunjukkan proses state:

State	Meaning
R	Running — sedang di CPU
S	Sleeping — menunggu event (normal)
D	Uninterruptible sleep — menunggu disk I/O
Z	Zombie — selesai tapi parent belum reap
T	Stopped — di-signal SIGSTOP
S+	Sleeping in foreground process group

D state yang banyak adalah red flag untuk disk I/O bottleneck. Kalau lo lihat banyak proses di D state, cek iostat -x 1 untuk lihat disk utilization.

Command Quick Reference

# Sort by CPU usage
P  (Capital P)

# Sort by memory usage
M  (Capital M)

# Sort by PID
N

# Show full command line
c

# Show tree view (parent-child processes)
V

# Filter processes
F5 or t  - tree view
k  - send signal (kill)

# Interactive filter
F  - type to filter
Z  - toggle case sensitivity

Debugging Workflow Real-World

Ini workflow yang pake ketika server mulai lag:

# 1. Buka htop, cek load average
# Load > CPU cores? ada bottleneck

# 2. Cek CPU bar — mana yang tinggi?
# wa tinggi - disk bottleneck
# si tinggi - softirq (network)
# sy tinggi - kernel (syscall intensive)
# us tinggi - user processes (normal)

# 3. Sort by CPU (P) - cek proses mana yang consuming

# 4. Sort by MEM (M) - cek memory consumers

# 5. Tekan S - tree view - lihat parent-child relationship

# 6. Tekan c - lihat full command untuk identify app

# 7. Tekan F - filter nama proses untuk focus

htop bukan cuma tool untuk "lihat CPU usage" — ini investigation tool yang powerful kalau lo tau cara baca setiap metriknya. Untuk parameter kernel yang lebih advanced terkait performance monitoring, cek juga panduan kernel tuning sysctl yang menjelaskan parameter-parameter yang mempengaruhi behavior yang lo lihat di htop.