VPS Ubuntu CPU Cao: Cách Tìm Process Gây Tải Và Xử Lý Đúng Nguyên Nhân

Khi VPS Ubuntu chậm, phản xạ thường gặp là mở top, thấy CPU cao rồi nghĩ ngay tới nâng cấp vCPU. Nhưng CPU cao chỉ là một triệu chứng.

Nguyên nhân có thể là:

• ứng dụng dùng CPU thật sự;
• process bị loop;
• cron job chạy đồng thời;
• PHP/Python/Node.js xử lý quá nhiều request;
• database query nặng;
• container chiếm CPU;
• system service lỗi;
• kernel xử lý nhiều interrupt;
• CPU đang chờ I/O;
• VPS bị steal time cao do host vật lý.

Quy trình đúng là đo → xác định process/service → xác định kiểu tải → xử lý nguyên nhân → đo lại.

Bước 1: xem load average

Chạy:

uptime

Ví dụ:

load average: 3.10, 2.50, 1.80

Ba số lần lượt là load trung bình 1, 5 và 15 phút.

Load không phải phần trăm CPU. Nó phản ánh số task đang chạy hoặc chờ tài nguyên ở mức hệ thống.

Một VPS 1 vCPU với load 4 kéo dài đáng lo hơn VPS 8 vCPU với load 4.

Xem số CPU:

nproc

Bước 2: dùng top

Chạy:

top

Quan tâm:

• %Cpu(s);
• %us — user space;
• %sy — kernel/system;
• %id — idle;
• %wa — I/O wait;
• %st — steal time trên máy ảo;
• process có %CPU cao.

Trong top, nhấn P để sort CPU.

Một process có thể hiển thị trên 100% CPU nếu dùng nhiều thread trên hệ thống nhiều core.

CPU cao hay I/O wait cao?

Nếu %wa cao, CPU có thể đang chờ storage chứ không phải app đang tính toán quá nhiều.

Ví dụ:

• backup đang đọc/ghi nhiều;
• database flush dữ liệu;
• disk latency cao;
• container log quá lớn;
• filesystem gần đầy.

Khi đó nâng CPU chưa chắc giúp gì.

Nếu disk đang đầy, xem bài VPS Ubuntu bị đầy ổ đĩa trước.

Bước 3: dùng mpstat xem từng CPU

Cài sysstat:

sudo apt update
sudo apt install -y sysstat

Theo dõi tổng thể:

mpstat 1 10

Theo từng CPU:

mpstat -P ALL 1 10

mpstat rất hữu ích khi một thread chỉ bão hòa một core trong khi tổng CPU toàn máy chưa lên 100%.

Bước 4: dùng pidstat để bắt process gây tải theo thời gian

top chỉ là snapshot tương tác. pidstat giúp theo dõi process qua từng interval.

Chạy:

pidstat -u 1 20

Các cột quan trọng gồm:

• PID;
• %usr;
• %system;
• %wait;
• %CPU;
• command.

Nếu muốn theo process cụ thể:

pidstat -u -p 1234 1

Thay 1234 bằng PID thật.

Bước 5: xem command đầy đủ

Từ PID:

ps -fp 1234

Hoặc:

ps -p 1234 -o pid,ppid,user,%cpu,%mem,etime,cmd

etime cho biết process đã chạy bao lâu.

Điều này giúp phân biệt:

• worker bình thường;
• cron job mới chạy;
• process cũ bị treo;
• script lạ;
• child process của service nào đó.

Bước 6: xác định process thuộc systemd service nào

Nếu process thuộc service:

systemctl status ten-service

Xem log:

journalctl -u ten-service --since "30 minutes ago"

Không restart ngay nếu chưa đọc log, vì restart có thể xóa dấu vết quan trọng của lỗi lặp.

Dùng systemd-cgtop để xem service/container group nào chiếm CPU

Chạy:

systemd-cgtop

Công cụ này hiển thị resource usage theo control group.

Sort theo CPU:

systemd-cgtop --order=cpu

Rất hữu ích khi một service có nhiều child process và khó nhìn trong top.

Lưu ý: dữ liệu phụ thuộc resource accounting/cgroup controller có được bật đầy đủ hay không.

Trường hợp PHP-FPM dùng CPU cao

Kiểm tra process:

ps aux --sort=-%cpu | grep php-fpm

Nguyên nhân có thể là:

• traffic tăng;
• bot crawl;
• plugin WordPress lỗi;
• PHP worker quá nhiều;
• request treo;
• database chậm làm request kéo dài.

Đừng chỉ tăng pm.max_children nếu RAM không đủ.

Nếu WordPress chậm, có thể tham khảo các bài tối ưu website trên HUONG CLOUD trước khi tăng tài nguyên.

Trường hợp MySQL dùng CPU cao

Kiểm tra:

ps aux --sort=-%cpu | head

Nếu mysqld đứng đầu, vào MySQL và xem:

SHOW FULL PROCESSLIST;

Sau đó bật slow query log nếu cần.

Xem bài MySQL chậm trên VPS để phân tích query và index sâu hơn.

Trường hợp Docker container dùng CPU cao

Xem realtime:

docker stats

Nếu một container bất thường:

docker logs --tail 200 ten-container

Xem process trong container:

docker top ten-container

Không restart container liên tục mà không xem log. Crash loop hoặc retry loop có thể quay lại ngay sau restart.

Cron job gây CPU spike

Kiểm tra cron:

crontab -l
sudo ls -lah /etc/cron.d/
sudo ls -lah /etc/cron.daily/

Xem journal:

journalctl --since "1 hour ago" | grep -i cron

Một tình huống thường gặp là nhiều backup/job nặng cùng chạy lúc 00:00.

Hãy lệch lịch chạy để tránh peak đồng thời.

Process lạ dùng CPU 100%

Nếu thấy process không nhận ra:

readlink -f /proc/1234/exe

Xem file đang mở:

sudo lsof -p 1234 | head -50

Xem network connection:

sudo ss -tpn

Không vội kill -9 nếu bạn chưa xác định đó là gì.

Nếu nghi compromise:

1. hạn chế network nếu cần;
2. lưu log/evidence;
3. kiểm tra user/login;
4. rotate credential;
5. kiểm tra persistence;
6. cân nhắc rebuild từ image sạch nếu không thể tin cậy hệ thống.

Khi nào dùng kill?

Ưu tiên graceful termination:

kill 1234

Mặc định gửi SIGTERM, cho process cơ hội cleanup.

Chỉ dùng:

kill -9 1234

khi process không phản hồi và bạn hiểu hậu quả.

SIGKILL không cho ứng dụng flush dữ liệu hoặc cleanup.

Với database, tuyệt đối không dùng kill -9 như bước xử lý đầu tiên.

CPU steal time trên VPS

Trong top, %st là thời gian VM muốn dùng CPU nhưng hypervisor dành CPU cho workload khác.

Nếu steal time cao kéo dài dù process trong VM không quá nặng, vấn đề có thể nằm ở contention của host vật lý.

Hãy đo trong nhiều khoảng thời gian trước khi kết luận.

Có thể dùng:

mpstat 1 30

và theo dõi %steal.

Một core 100% nhưng tổng CPU chỉ 25%

Giả sử VPS có 4 vCPU và một ứng dụng single-thread dùng tối đa một core.

Bạn có thể thấy:

• một core 100%;
• tổng CPU khoảng 25%;
• ứng dụng vẫn chậm.

Lúc này thêm nhiều core chưa chắc cải thiện nếu ứng dụng không parallelize được.

Bạn cần:

• tối ưu thuật toán/query;
• chia workload;
• dùng worker process;
• hoặc CPU có hiệu năng single-core tốt hơn.

CPU cao do traffic tăng

Kiểm tra Nginx access log:

sudo tail -n 200 /var/log/nginx/access.log

Đếm IP phổ biến:

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Lệnh chỉ đọc log, không block IP.

Nếu traffic hợp lệ tăng, cần scale hoặc cache.

Nếu bot/abuse, cân nhắc:

• rate limiting;
• CDN/WAF;
• application cache;
• firewall policy phù hợp.

CPU cao sau khi deploy

Nếu lỗi bắt đầu ngay sau release:

• kiểm tra commit mới;
• xem error log;
• so sánh request latency;
• rollback nếu cần;
• kiểm tra migration/database.

Nếu bạn đã tự động deploy, bài Deploy VPS bằng GitHub Actions có phần về health check và rollback.

Đừng quên memory pressure

CPU có thể tăng do hệ thống liên tục reclaim memory hoặc swap.

Kiểm tra:

free -h
vmstat 1 10

Nếu swap in/out nhiều, nguyên nhân có thể là thiếu RAM chứ không phải thiếu CPU.

Theo dõi thay vì chỉ xử lý khi có sự cố

Nếu CPU spike xảy ra lúc 3 giờ sáng nhưng bạn chỉ SSH vào lúc 8 giờ, top không còn giúp được nhiều.

Bạn cần time-series monitoring.

Có thể triển khai Prometheus, Node Exporter và Grafana để lưu lịch sử CPU, load và resource usage.

Quy trình chẩn đoán nhanh 10 phút

Phút 1–2

uptime
nproc
free -h
df -h

Phút 3–4

top
mpstat -P ALL 1 5

Phút 5–6

pidstat -u 1 10

Phút 7–8

ps -p PID -o pid,ppid,user,%cpu,%mem,etime,cmd

Xác định service/container.

Phút 9–10

Xem log:

journalctl -u ten-service --since "30 minutes ago"

hoặc application log tương ứng.

Sau đó mới quyết định restart, rollback, scale hay tối ưu.

Sai lầm thường gặp

Thấy CPU cao là reboot VPS

Reboot làm mất trạng thái hiện tại và không giải quyết nguyên nhân lặp.

Kill process ngay lập tức

Có thể làm mất dữ liệu hoặc khiến supervisor restart process rồi CPU lại cao.

Chỉ nhìn tổng CPU

Một app single-thread có thể nghẽn một core dù tổng CPU còn thấp.

Bỏ qua %wa và %st

I/O wait và steal time cho thấy hai loại bottleneck hoàn toàn khác CPU compute.

Nâng VPS trước khi đo

Nâng CPU có thể che lỗi code/query trong thời gian ngắn nhưng không xử lý gốc rễ.

Checklist xử lý CPU cao

• Xem load average.
• Kiểm tra số vCPU.
• Xem %us, %sy, %wa, %st.
• Xem từng CPU bằng mpstat.
• Tìm process bằng pidstat.
• Xác định service/container.
• Đọc log trước khi restart.
• Kiểm tra RAM/swap.
• Kiểm tra disk I/O nếu %wa cao.
• Kiểm tra traffic nếu web server tăng tải.
• So sánh với deployment/cron gần nhất.
• Theo dõi lại sau khi sửa.

FAQ

CPU 100% có nguy hiểm không?

CPU 100% trong thời gian ngắn có thể hoàn toàn bình thường với build, compression hoặc batch job. Điều đáng lo là CPU bão hòa kéo dài và gây latency hoặc queue tăng.

Load average bao nhiêu là cao?

Không có một con số cố định. Hãy so với số vCPU, loại workload và xu hướng 1/5/15 phút.

Vì sao top báo process hơn 100% CPU?

Trên máy nhiều CPU/core, process đa luồng có thể sử dụng nhiều hơn một core nên phần trăm có thể vượt 100%.

%wa cao có phải CPU yếu không?

Không. %wa cao thường liên quan CPU chờ I/O, nên cần kiểm tra storage hoặc workload đọc/ghi.

Có nên reboot khi CPU cao?

Chỉ khi cần khôi phục dịch vụ khẩn cấp và đã chấp nhận mất thông tin chẩn đoán. Tốt hơn là xác định process và nguyên nhân trước.

Kết luận

Khi VPS Ubuntu CPU cao, đừng bắt đầu bằng reboot hoặc nâng gói. Hãy phân biệt compute, I/O wait, steal time và single-core bottleneck; sau đó tìm process bằng top, pidstat, mpstat và systemd-cgtop.

Việc đo đúng giúp bạn biết lúc nào cần tối ưu code, query, cron, Docker, storage hoặc thực sự cần thêm CPU.

Nếu monitoring cho thấy workload hợp lệ đã thường xuyên chạm giới hạn CPU sau khi tối ưu, bạn có thể tham khảo các gói VPS tại HUONG CLOUD và lựa chọn tài nguyên theo tải thực tế thay vì phỏng đoán.

Nguồn tham khảo

• Ubuntu Manpages — top: https://manpages.ubuntu.com/manpages/noble/man1/top.1.html
• Ubuntu Manpages — pidstat: https://manpages.ubuntu.com/manpages/noble/man1/pidstat.1.html
• Ubuntu Manpages — mpstat: https://manpages.ubuntu.com/manpages/noble/man1/mpstat.1.html
• Ubuntu Manpages — systemd-cgtop: https://manpages.ubuntu.com/manpages/noble/man1/systemd-cgtop.1.html