Khi nào bạn thực sự cần htop và iotop?
Có một buổi tối server bỗng dưng chậm bất thường — response time tăng từ 200ms lên 3 giây, CPU load average nhảy lên 8.0 trong khi máy chỉ có 4 cores. Mình mở top ra nhìn, thấy màn hình nhảy liên tục, không biết process nào đang ngốn tài nguyên. Sau khi chuyển sang htop, mình tìm ra ngay: một cron job backup đang chạy rsync đồng thời với MySQL dump, đẩy disk I/O lên 100%. Cần thêm iotop để xác nhận điều đó.
Từ khi cài hai thứ này trên server Ubuntu 22.04 / 4GB RAM, thời gian xử lý sự cố giảm từ 30 phút mò mẫm xuống dưới 5 phút. Không phải phóng đại — chỉ là dùng đúng công cụ đúng việc: htop nhìn CPU/RAM theo process, iotop nhìn disk I/O theo process.
Bài này đi thẳng vào thực chiến — không copy từ man page.
Cài đặt htop và iotop
Trên Ubuntu/Debian
sudo apt update
sudo apt install htop iotop -yTrên CentOS/AlmaLinux/RHEL
sudo dnf install htop iotop -y
# Hoặc nếu dùng yum (CentOS 7 cũ):
sudo yum install htop iotop -yKiểm tra version sau cài đặt
htop --version
# htop 3.2.2
iotop --version
# iotop 0.6Lưu ý: iotop cần kernel hỗ trợ CONFIG_TASK_IO_ACCOUNTING — hầu hết distro hiện đại đã có sẵn. Nếu chạy mà báo “kernel not configured for task I/O accounting”, cách nhanh nhất là cài iotop-c thay thế — bản viết lại bằng C, ít yêu cầu hơn và đang được maintain tích cực hơn bản gốc.
Cấu hình và sử dụng htop chi tiết
Đọc màn hình htop
Chạy htop với sudo để thấy process của mọi user — không có sudo chỉ thấy của mình:
sudo htopLayout chia 3 vùng rõ ràng:
- Header (phần trên): CPU bars, memory, swap, load average, uptime
- Process list (giữa): Danh sách process với các cột thông số
- Footer (dưới): Phím tắt
Phần CPU bars: mỗi bar là một core (hoặc thread). Màu xanh lá = user processes, màu đỏ = kernel/system, màu vàng = nice (low priority processes). Khi bar đỏ chiếm nhiều, đó là dấu hiệu kernel đang xử lý nhiều — thường do I/O wait hoặc interrupt.
Các cột quan trọng cần chú ý
- PID: Process ID
- USER: Owner của process
- PRI/NI: Priority và Nice value (NI từ -20 đến 19, thấp hơn = ưu tiên cao hơn)
- VIRT/RES/SHR: Virtual/Resident/Shared memory. RES là con số thực tế cần quan tâm — đây là RAM vật lý process đang dùng
- S: State — R (running), S (sleeping), D (disk wait — process đang chờ disk, khả năng I/O bottleneck)
- CPU%: Phần trăm CPU của process này
- MEM%: Phần trăm RAM tổng
- TIME+: Tổng CPU time đã dùng
- COMMAND: Tên lệnh
Phím tắt thực dụng
| Phím | Chức năng |
|---|---|
F6 hoặc > |
Chọn cột để sort (mặc định sort theo CPU%) |
F4 hoặc \ |
Filter process theo tên |
F5 |
Chuyển tree view — thấy rõ parent/child process |
F9 |
Kill process (chọn signal) |
Space |
Tag process (để kill nhiều process cùng lúc) |
u |
Filter theo user |
H |
Ẩn/hiện user threads |
t |
Toggle tree view |
Tùy chỉnh cột hiển thị
Nhấn F2 (Setup) → Columns → thêm/bớt cột tùy ý. Mình thường thêm IO_READ_RATE và IO_WRITE_RATE để thấy disk activity ngay trong list process — khỏi cần mở iotop riêng. Cấu hình lưu tại ~/.config/htop/htoprc.
Ví dụ file ~/.config/htop/htoprc với cột I/O được bật:
# Xem cấu hình hiện tại
cat ~/.config/htop/htoprc# Đoạn quan trọng trong htoprc
fields=0 48 17 18 38 39 40 2 46 47 49 1
# 48 = IO_READ_RATE, 49 = IO_WRITE_RATECấu hình và sử dụng iotop
Chạy iotop cơ bản
iotop cần root để đọc I/O accounting của tất cả processes:
sudo iotopKết quả ra ngay: tốc độ đọc/ghi của từng process, header hiển thị tổng throughput toàn hệ thống.
Các option thực dụng
# Chỉ hiện process đang có I/O activity (bỏ qua process idle)
sudo iotop -o
# Batch mode — xuất text, dùng để log hoặc grep
sudo iotop -b -o -n 5
# -b: batch mode, -n 5: lấy 5 lần snapshot rồi thoát
# Chỉ xem process của 1 user cụ thể
sudo iotop -u www-data
# Kết hợp: only + batch + interval 2 giây
sudo iotop -o -b -d 2 -n 10Đọc thông số iotop
- DISK READ / DISK WRITE: Tốc độ I/O hiện tại của process (KB/s, MB/s)
- SWAPIN: Phần trăm thời gian process bị swap — nếu > 0 thì RAM đã bắt đầu không đủ rồi
- IO>: Phần trăm thời gian process bị block chờ I/O — đây là số quan trọng nhất để phát hiện bottleneck
- Total DISK READ / WRITE (dòng đầu): Tổng throughput toàn hệ thống
- Actual DISK READ / WRITE (dòng thứ hai): Throughput thực tế đến phần cứng (sau kernel buffer)
Khi Actual DISK READ cao hơn hẳn Total DISK READ, đó là kernel đang đọc trước (readahead) — bình thường. Khi IO> của một process luôn > 50%, process đó đang bị nghẽn I/O.
Kiểm tra và monitoring thực tế
Scenario 1: Tìm process ngốn CPU
# Mở htop, sort theo CPU% (mặc định)
sudo htop
# Nhấn F6 → chọn PERCENT_CPU → Enter
# Các process tốn CPU nhất sẽ lên đầuphp-fpm hoặc mysqld chiếm > 80% CPU liên tục? Mở slow query log ra ngay — thường có một con query đang chạy fullscan ẩn ở đó.
Scenario 2: Điều tra memory leak
# Sort theo RES (resident memory)
# Trong htop nhấn F6 → chọn M_RESIDENT
# Hoặc nhấn phím 'm' để toggle sort theo memoryRES tăng liên tục không bao giờ xuống — đó là memory leak, không cần chẩn đoán gì thêm. Mình từng thấy một Node.js app leo từ 200MB lên 3GB trong 6 tiếng — htop sort theo memory phát hiện ngay.
Scenario 3: Chẩn đoán server lag bằng iotop
# Chạy iotop với only mode để thấy process đang active I/O
sudo iotop -o
# Đồng thời trong terminal khác, kiểm tra load average
watch -n 1 'cat /proc/loadavg'Load average cao mà CPU% trong htop thấp? Thủ phạm gần như chắc chắn là I/O. Chạy iotop -o — process đang block chờ disk sẽ hiện lên ngay đầu danh sách.
Scenario 4: Log I/O activity để phân tích sau
# Ghi log iotop trong 60 giây (30 lần, mỗi lần cách 2 giây)
sudo iotop -b -o -d 2 -n 30 > /tmp/iotop_$(date +%Y%m%d_%H%M%S).log 2>&1 &
# Xem log sau
grep -v '^$' /tmp/iotop_*.log | head -50Script đơn giản để alert khi I/O cao
#!/bin/bash
# /usr/local/bin/check_io.sh
# Cron: */5 * * * * /usr/local/bin/check_io.sh
THRESHOLD=50 # MB/s
LOG=/var/log/io_alert.log
# Lấy tổng write rate (MB/s)
WRITE_RATE=$(sudo iotop -b -o -n 1 -d 1 2>/dev/null | \
grep 'Total DISK WRITE' | \
awk '{print $9}')
if (( $(echo "$WRITE_RATE > $THRESHOLD" | bc -l) )); then
echo "$(date '+%Y-%m-%d %H:%M:%S') ALERT: Disk write ${WRITE_RATE} MB/s" >> $LOG
# Lấy top 3 process đang ghi nhiều nhất
sudo iotop -b -o -n 1 2>/dev/null | head -15 >> $LOG
fiKết hợp với vmstat để có bức tranh toàn cảnh
# vmstat xuất thông số mỗi 2 giây
vmstat 2
# Cột 'b': số process đang blocked chờ I/O
# Cột 'wa': I/O wait % (nếu > 20% liên tục thì disk là bottleneck)
# Cột 'si/so': swap in/out (nếu > 0 liên tục thì RAM không đủ)Workflow mình hay dùng khi có sự cố: vmstat 2 để xem tổng quan → nếu wa cao thì mở iotop -o để tìm process → nếu CPU load cao thì htop sort theo CPU → nếu memory thấp thì sort theo RES. Ba bước là ra ngay vấn đề.
Một điều mình học được sau nhiều tháng: đừng chỉ nhìn số tức thời. htop và iotop chỉ là snapshot — bottleneck thực sự hay xuất hiện đúng giờ cao điểm, không phải lúc bạn đang nhìn. Kết hợp với sar hoặc Netdata để có dữ liệu lịch sử — htop/iotop sẽ là công cụ drill-down khi bạn đã biết vấn đề xảy ra lúc nào.
