Chỉ số CPU chạm ngưỡng 100% chỉ cho biết tài nguyên tính toán đang được dùng hết công suất, nhưng chưa nói lên nguyên nhân cốt lõi: máy chủ đang bận xử lý logic ứng dụng, bị nghẽn đọc ghi ổ đĩa (I/O wait), hay đang bị tranh chấp tài nguyên vật lý từ nhà cung cấp đám mây (steal time).
Khởi động lại máy chủ trong tình huống này chỉ xóa sạch dấu vết điều tra mà không sửa được gốc rễ vấn đề. Trước khi can thiệp, bạn cần phân rã con số 100% để biết tiến trình nào đang chiếm CPU và loại tải thực sự là gì.
CPU cao chỉ trở thành tín hiệu hữu ích khi được đặt cạnh tác động, loại tải và sự kiện cùng thời điểm.
Bước 1: Xác nhận mức độ ảnh hưởng thực tế tới người dùng
Trước khi vội vàng can thiệp vào các tiến trình hệ thống, hãy đối chiếu chỉ số tải với trải nghiệm thực tế của người dùng:
- Website có bị tăng độ trễ (latency) hoặc xuất hiện các mã lỗi HTTP 502/504 hay không?
- Lỗi xảy ra trên toàn bộ các trang hay chỉ xuất hiện ở một tính năng nghiệp vụ cụ thể (tìm kiếm, xuất báo cáo, thanh toán)?
- Lưu lượng truy cập (request rate) có tăng đột biến cùng thời điểm không?
- Đợt tăng tải này có trùng khớp với một sự kiện đã biết: cronjob sao lưu lúc 2 giờ sáng, đợt quét virus tự động, hay một chiến dịch quảng cáo vừa kích hoạt?
Nếu website vẫn phản hồi mượt mà dưới 200ms và mức tải CPU tăng là do tác vụ sao lưu theo lịch đang nén dữ liệu, đây là khối lượng công việc hợp lệ đang vận hành bình thường. Bạn chỉ cần theo dõi để đảm bảo nó hoàn tất theo đúng thời gian dự kiến.
Nếu người dùng đang gặp tình trạng treo trang hoặc xuất hiện lỗi hàng loạt, hãy tuân thủ nguyên tắc điều phối tại bài Quy trình 30 phút đầu khi website production gặp sự cố.
Bước 2: Hiểu đúng ba con số Load Average
Lệnh uptime hoặc dòng đầu tiên của top luôn hiển thị 3 con số đại diện cho mức tải trung bình trong 1 phút, 5 phút và 15 phút:
load average: 4.12, 2.85, 1.10Một sai lầm rất phổ biến là coi các con số này tương đương với tỷ lệ phần trăm (nghĩ rằng load 4.12 là 4%). Trên nhân Linux, Load Average đo lường số lượng tiến trình trung bình đang chạy trên CPU hoặc đang nằm trong hàng đợi chờ được cấp phát tài nguyên (bao gồm cả các tiến trình chờ I/O đĩa cứng không thể ngắt được - uninterruptible sleep state).
Để hiểu đúng ý nghĩa của Load Average:
- Phải so sánh với số lượng vCPU: Một VPS có 4 vCPU thì mức load 4.00 có nghĩa là các lõi CPU đang được tận dụng tối đa công suất mà không bị ùn ứ hàng đợi. Nhưng nếu VPS đó chỉ có 1 vCPU, mức load 4.00 đồng nghĩa với việc đang có 3 tiến trình phải xếp hàng chờ đợi được xử lý.
- Quan sát xu hướng biến thiên:
load 1m(4.12) cao hơn nhiều so vớiload 15m(1.10): một đợt tăng tải lớn vừa mới xuất hiện.load 1m(0.50) thấp hơn nhiều so vớiload 15m(4.50): sự cố hoặc đợt cao điểm đã đi qua, hệ thống đang dần hạ nhiệt.
Kiểm tra số lượng core trên máy chủ bằng lệnh:
nprocBước 3: Phân tích 4 trạng thái tải CPU: user, system, iowait và steal
Khi mở công cụ top, hãy quan sát dòng hiển thị trạng thái CPU (%Cpu(s)). Các con số viết tắt này cho bạn biết chính xác thời gian tính toán của CPU đang bị tiêu tốn vào đâu:
1. %us (User Time) cao: Logic ứng dụng chiếm dụng
Thời gian CPU xử lý các tác vụ trong không gian người dùng (User Space): mã nguồn PHP, Node.js, Python, Java, hoặc tiến trình MySQL đang tính toán dữ liệu.
- Ý nghĩa: Máy chủ đang thực sự xử lý thuật toán hoặc truy vấn dữ liệu.
- Hướng kiểm tra: Tìm kiếm các câu truy vấn database chạy chậm, vòng lặp vô hạn trong mã nguồn, hoặc lượng traffic người dùng thực tế đang vượt quá năng lực phục vụ của số lượng worker hiện tại.
2. %sy (System Time) cao: Tầng nhân Linux quá tải
Thời gian CPU phục vụ các lời gọi hàm hệ thống (System Calls) của kernel: xử lý gói tin mạng dồn dập, chuyển đổi ngữ cảnh tiến trình (context switching), hoặc đọc ghi tệp tin liên tục.
- Ý nghĩa: Tải cao phát sinh từ việc quản lý tài nguyên của hệ điều hành, không phải từ logic tính toán của ứng dụng.
- Hướng kiểm tra: Tấn công mạng SYN flood làm tràn card mạng, số lượng tiến trình/thread được sinh ra quá nhiều gây tranh chấp, hoặc lỗi driver phần cứng.
3. %wa (I/O Wait) cao: Nghẽn cổ chai ổ đĩa cứng
CPU hoàn toàn không bận tính toán; nó đang phải dừng hoạt động (idle) để ngồi chờ ổ đĩa cứng hoặc mạng lưu trữ đọc ghi xong dữ liệu.
- Ý nghĩa: Điểm nghẽn không nằm ở năng lực tính toán của CPU, mà nằm ở tốc độ đọc ghi của ổ đĩa (IOPS hoặc băng thông đĩa đã chạm trần).
- Hướng kiểm tra: Một câu truy vấn SQL quét toàn bộ bảng hàng triệu dòng buộc ổ đĩa phải liên tục đọc từ disk, tác vụ backup nén file đồng thời, hoặc phân vùng Swap đang bị đọc ghi dồn dập do cạn kiệt RAM. Trường hợp này được phân tích sâu tại bài Website chậm nhưng CPU thấp: nên kiểm tra gì tiếp theo?.
4. %st (Steal Time) cao: Tranh chấp tài nguyên từ máy chủ vật lý
Hiện tượng chỉ xảy ra trên môi trường ảo hóa (VPS / Cloud Instance). Đây là tỷ lệ thời gian mà CPU ảo (vCPU) của bạn có công việc cần chạy nhưng máy chủ vật lý (Hypervisor) bên dưới của nhà cung cấp đang bận phục vụ các VPS khác cùng chia sẻ chung con chip đó (hiện tượng "hàng xóm ồn ào" - noisy neighbor).
- Ý nghĩa: VPS của bạn bị chiếm dụng tài nguyên bởi các máy chủ khác trên cùng cụm phần cứng của nhà cung cấp.
- Hướng kiểm tra: Nếu chỉ số
%stthường xuyên vượt quá 10% - 20% trong khi ứng dụng của bạn không tăng tải, hãy mở ticket yêu cầu nhà cung cấp chuyển VPS của bạn sang cụm máy chủ vật lý khác hoặc nâng cấp lên gói tài nguyên chuyên dụng (Dedicated CPU).
Bước 4: Định vị chính xác tiến trình gây tải
Để tìm đích danh phần mềm hoặc đoạn mã nào đang chiếm dụng tài nguyên, bạn không nên chỉ dựa vào một ảnh chụp màn hình của top. Hãy sử dụng các công cụ chuyên dụng để theo dõi nhiều mẫu liên tiếp:
Sử dụng htop để quan sát trực quan
Chạy htop (nếu máy đã cài đặt) và bấm phím P để sắp xếp danh sách tiến trình theo mức độ sử dụng CPU giảm dần:
- Bấm phím F5 để chuyển sang chế độ cây (Tree View): giúp bạn nhận diện tiến trình cha và toàn bộ các tiến trình con được sinh ra (ví dụ: tiến trình cha
nginx: mastersinh ra bao nhiêu worker con). - Bấm phím H để ẩn/hiện các luồng con (threads).
Sử dụng pidstat để đo lường qua nhiều mẫu
Công cụ pidstat (thuộc gói sysstat) là vũ khí điều tra chuẩn xác nhất vì nó lấy mẫu theo thời gian thực thay vì chỉ hiển thị một khoảnh khắc:
# Lấy mẫu 5 lần, mỗi lần cách nhau 2 giây cho các tiến trình đang hoạt động
pidstat 2 5Kết quả sẽ cho bạn thấy danh sách các PID sử dụng CPU ổn định qua từng giây:
UID PID %usr %system %guest %wait %CPU CPU Command
33 14205 85.50 4.50 0.00 0.00 90.00 1 php-fpm
1001 18902 78.00 2.00 0.00 0.00 80.00 0 mysqldDựa vào PID, hãy tra cứu chi tiết đường dẫn thực thi và dòng lệnh khởi chạy tiến trình đó:
ls -l /proc/<PID>/exe
cat /proc/<PID>/cmdlineBước 5: Đối chiếu tiến trình với các biến số cùng thời điểm
Khi đã tìm được tiến trình chiếm 90% CPU, đừng vội vàng chạy lệnh kill -9 để tiêu diệt nó. Bạn cần phân loại tiến trình đó thuộc nhóm nào:
- Đây là tiến trình dịch vụ web hợp lệ (
mysqld,php-fpm,node):
- Kiểm tra log ứng dụng hoặc slow query log của MySQL xem câu lệnh SQL nào đang chạy tốn nhiều thời gian.
- Kiểm tra access log của Nginx xem có IP nào đang cào dữ liệu (scraping) hoặc tấn công từ chối dịch vụ (DDoS) bằng cách gửi hàng nghìn request vào một endpoint tìm kiếm nặng hay không.
- Đây là một tác vụ chạy ngầm hợp lệ nhưng chạy sai khung giờ:
- Một cronjob sao lưu cơ sở dữ liệu hoặc script tạo sitemap bị lập lịch chạy vào đúng khung giờ cao điểm mua hàng (12h trưa hoặc 20h tối).
- Đây là tiến trình độc hại (Malware / Crypto Miner):
- Tiến trình chạy dưới quyền một user lạ, tệp thực thi nằm trong thư mục
/tmphoặc/dev/shmvới những cái tên ngẫu nhiên (nhưkdevtmpfsi,xmrig). Trường hợp này máy chủ đã bị xâm nhập bảo mật qua lỗ hổng ứng dụng.
Bước 6: Các giải pháp hạ tải theo thứ tự an toàn
Tùy vào nguyên nhân vừa xác định, hãy lựa chọn giải pháp can thiệp có phạm vi ảnh hưởng nhỏ nhất:
Phương án 1: Tạm dừng hoặc dời lịch các tác vụ nền
Nếu một cronjob nén backup hoặc xuất dữ liệu đang chiếm trọn CPU:
- Tạm dừng tiến trình bằng lệnh:
kill -STOP <PID>(tiến trình sẽ tạm ngừng tính toán mà không bị mất dữ liệu). Khi hệ thống vãn khách, bạn có thể cho chạy tiếp bằngkill -CONT <PID>. - Hoặc cấu hình giảm độ ưu tiên CPU của tiến trình bằng lệnh
renice:
# Tăng giá trị nice lên 19 (mức ưu tiên CPU thấp nhất cho background job)
sudo renice -n 19 -p <PID>Phương án 2: Chặn IP cào dữ liệu hoặc kích hoạt Rate Limit
Nếu CPU 100% do bot cào dữ liệu liên tục:
- Chặn IP đó ngay lập tức tại Cloud Firewall hoặc UFW:
sudo ufw insert 1 deny from <IP_tan_cong> to any- Kích hoạt tính năng giới hạn tần suất truy cập (
limit_req_zone) trong Nginx để bảo vệ các endpoint tìm kiếm.
Phương án 3: Khởi động lại dịch vụ bị kẹt logic
Nếu một worker PHP-FPM hoặc container Node.js bị rơi vào vòng lặp vô hạn do lỗi code:
- Lưu lại các dòng log lỗi mới nhất của tiến trình.
- Khởi động lại dịch vụ tương ứng:
sudo systemctl restart php8.2-fpmhoặcdocker compose restart backend. - Theo dõi xem CPU có bị tăng vọt trở lại hay không. Nếu lỗi lập tức xuất hiện lại, nguyên nhân nằm ở một yêu cầu người dùng liên tục kích hoạt đoạn code lỗi; bạn cần nhanh chóng rollback phiên bản theo hướng dẫn tại bài Rollback Docker Compose an toàn.
Khi nào mới thực sự cần reboot máy chủ?
Reboot toàn bộ máy chủ là giải pháp cuối cùng và chỉ được áp dụng khi:
- Hệ điều hành bị mất hoàn toàn khả năng tương tác: lệnh SSH không phản hồi, không thể mở thêm terminal do cạn kiệt bảng tiến trình (
fork: retry: Resource temporarily unavailable). - Nhân Linux bị lỗi treo phân tầng hoặc kernel panic do xung đột driver phần cứng.
- Bạn đã kiểm tra và chuẩn bị đầy đủ các biện pháp an toàn theo checklist khi nào nên reboot VPS.
Xác nhận kết quả sau khi hạ tải
Sau khi thực hiện các biện pháp can thiệp, hãy kiểm tra hệ thống theo 2 góc độ:
- Từ bên ngoài: Truy cập website từ mạng độc lập, đo lường độ trễ phản hồi và tỷ lệ lỗi HTTP 5xx xem đã trở về mức baseline bình thường chưa.
- Từ bên trong: Quan sát biểu đồ CPU trong ít nhất 15 phút. Các chỉ số
%us,%sy,%wađã hạ xuống mức an toàn (< 70%) và 3 con số Load Average trênuptimecó xu hướng giảm dần đều theo thời gian.
Checklist điều tra nhanh sự cố CPU 100%
- ☐ Đã xác nhận người dùng có bị ảnh hưởng thực tế (latency, timeout) hay đây chỉ là tác vụ hợp lệ chạy ngầm.
- ☐ Đã kiểm tra số lượng core máy chủ (
nproc) và phân tích đúng 3 con số Load Average. - ☐ Đã xác định rõ tỷ lệ thời gian CPU: do ứng dụng (
%us), do hệ điều hành (%sy), do nghẽn ổ đĩa (%wa) hay do máy chủ ảo hóa bị tranh chấp (%st). - ☐ Đã dùng
pidstathoặchtoplấy mẫu để tìm đích danh PID và dòng lệnh khởi chạy tiến trình gây tải. - ☐ Đã kiểm tra log Nginx và log ứng dụng để tìm câu truy vấn chậm, IP cào dữ liệu hoặc vòng lặp lỗi.
- ☐ Ưu tiên hạ mức ưu tiên (
renice), chặn IP hoặc restart dịch vụ đơn lẻ thay vì reboot toàn bộ máy chủ. - ☐ Đã theo dõi hệ thống qua ít nhất 15–30 phút sau khi hạ tải để đảm bảo sự cố không bị bùng phát trở lại.
Biết cách đọc đúng các chỉ số CPU và bình tĩnh lần theo dấu vết của từng tiến trình sẽ giúp bạn làm chủ hoàn toàn máy chủ của mình, giải quyết dứt điểm các đợt tăng tải mà không bao giờ phải dựa vào giải pháp phó mặc số phận như nút bấm reboot.
