3 Lệnh Cứu Hộ Server Linux Khi Bị Treo Hoặc CPU/RAM 100%

Là một kỹ sư vận hành hệ thống, chắc chắn bạn đã từng nhận được cuộc gọi khẩn cấp lúc nửa đêm: "Server prod bị treo cứng, SSH vào cực kỳ chậm hoặc connection timeout!". Trong tình huống ngàn cân treo sợi tóc, việc gõ sai lệnh hoặc reboot server mù quáng có thể làm mất toàn bộ dữ liệu log sự cố và khiến khách hàng nổi giận.

Dưới đây là quy trình chẩn đoán 3 bước giúp bạn lấy lại quyền kiểm soát máy chủ chỉ trong 60 giây.

Bước 1: Đánh giá tổng thể áp lực hệ thống với `uptime`

Lệnh đầu tiên bạn phải gõ ngay sau khi vừa đăng nhập được vào terminal là:

uptime

Kết quả mẫu:

 02:14:15 up 45 days,  3:12,  2 users,  load average: 18.42, 12.10, 4.05

Ý nghĩa của Load Average:

Ba con số tương ứng với mức tải trung bình trong 1 phút, 5 phút và 15 phút vừa qua.
- Quy tắc số lõi CPU: Chạy lệnh nproc để biết server có bao nhiêu core CPU.
- Ví dụ server có 4 core:
- Load < 4.0: Hệ thống còn an toàn, tài nguyên thoải mái.
- Load = 4.0: 100% tài nguyên CPU đang được sử dụng trọn vẹn.
- Load = 18.42: Đang có 14.42 tiến trình phải xếp hàng chờ CPU hoặc nghẽn Disk I/O!
- Độ dốc của tải: So sánh con số 1 phút (18.42) với 15 phút (4.05) cho thấy sự cố mới bùng phát dữ dội gần đây, không phải tải nền mãn tính.

Bước 2: Chẩn đoán nguyên nhân nghẽn bằng `vmstat 1 5`

Nhiều người có thói quen mở top hoặc htop, nhưng khi server đang quá tải, top tiêu tốn rất nhiều tài nguyên để render giao diện, khiến server càng đơ thêm. Thay vào đó, hãy dùng vmstat:

vmstat 1 5

Kết quả mẫu:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  3      0 124500  45200 954000    0    0  8400  3200 1200 4500 85 10  0  5  0

4 chỉ số sinh tử cần nhìn ngay:

r (runnable): Số tiến trình đang chạy hoặc chờ CPU. Nếu r > nproc, bạn đang bị quá tải CPU do tính toán thuật toán, crypto hoặc vòng lặp vô tận.
b (blocked): Số tiến trình bị kẹt ở trạng thái Uninterruptible Sleep (D state) — thường do chờ ổ cứng đọc/ghi hoặc mạng NFS bị treo.
si / so (swap in / swap out): Nếu si và so lớn hơn 0 liên tục, RAM vật lý đã cạn kiệt và hệ thống đang phải tráo bộ nhớ ra đĩa cứng (Swapping). Server sẽ lag kinh hoàng!
wa (iowait): Phần trăm thời gian CPU ngồi rảnh chờ ổ đĩa. Nếu wa > 20%, thủ phạm là nghẽn I/O đĩa cứng (database query thiếu index, log ghi bừa bãi).

Bước 3: Tìm chính xác thủ phạm và xử lý dứt điểm

Tìm Top 5 tiến trình ngốn CPU nhất:

ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%cpu | head -n 6

Tìm Top 5 tiến trình ngốn RAM nhất:

ps -eo pid,ppid,user,%cpu,%mem,cmd --sort=-%mem | head -n 6

Xử lý tiến trình rogue một cách bài bản:

Tuyệt đối không gõ ngay kill -9 <PID>! Hãy tuân thủ văn hóa Unix:
1. Bước 1 — Báo hiệu hạ cánh mềm (SIGTERM - 15):
bash kill -15 <PID>
Lệnh này cho tiến trình 10-30 giây để đóng kết nối database, flush buffer ghi xuống đĩa, tránh làm hỏng dữ liệu.
2. Bước 2 — Chỉ cưỡng chế khi tiến trình không phản hồi (SIGKILL - 9):
bash kill -9 <PID>

Checklist phòng thủ chủ động

Luôn cấu hình cgroups / systemd slice: Giới hạn RAM tối đa cho các service như PHP-FPM, Node.js để khi bị leak memory, chúng không kéo theo sập toàn bộ máy chủ SSH.
Giám sát tải bằng Prometheus Node Exporter: Thiết lập cảnh báo khi node_load1 / count(node_cpu_seconds_total{mode="idle"}) > 2 liên tục trong 3 phút.

Từ khoá chủ đề:#VibeDevOps#Linux#Sysadmin#DevOpsVietnam#SRE#Production#Terminal