VPS 100% CPU? Nguyên nhân & hướng dẫn xử lý triệt để từ A-Z

Tác giả: Tran Thao 20 tháng 07, 2025

Sự cố VPS 100% CPU là một trong những “cơn ác mộng” tồi tệ nhất đối với bất kỳ quản trị viên website nào. Tình trạng này không chỉ làm tê liệt hiệu suất máy chủ mà còn trực tiếp khiến website của bạn trở nên chậm như rùa hoặc không thể truy cập.

Hậu quả của nó rất rõ ràng và đau đớn. Website của bạn trở nên chậm như rùa, gây khó chịu cho người truy cập. Khách hàng tiềm năng có thể rời đi chỉ sau vài giây chờ đợi, dẫn đến mất doanh thu. Các phiên làm việc SSH bị treo, biến mọi nỗ lực quản trị thành một cuộc chiến vô vọng.

Nhiều người dùng, đặc biệt khi mới sử dụng VPS giá rẻ, thường chọn giải pháp đơn giản nhất: reboot lại VPS. Đôi khi nó hiệu quả, nhưng đó chỉ là liều thuốc giảm đau tạm thời. Nếu không tìm ra và xử lý tận gốc nguyên nhân, “cơn ác mộng” 100% CPU sẽ sớm quay trở lại, có thể vào đúng lúc bạn ít ngờ tới nhất.

Bài viết này sẽ là kim chỉ nam giúp bạn thoát khỏi vòng lặp “reboot và hy vọng”. Chúng tôi sẽ cung cấp một quy trình chẩn đoán bài bản, trang bị cho bạn những công cụ cần thiết và kiến thức chuyên sâu để “bắt bệnh” và “chữa trị” dứt điểm tình trạng quá tải CPU.

VPS 100% CPU_ Nguyên nhân & hướng dẫn xử lý triệt để từ A-Z

Hiểu đúng về lỗi CPU 100% trên VPS

Trước khi lao vào sửa chữa, điều quan trọng là phải hiểu rõ kẻ thù của chúng ta. CPU, hay Central Processing Unit, chính là bộ não của máy chủ. Mọi yêu cầu, từ việc hiển thị một trang web đến thực thi một truy vấn cơ sở dữ liệu, đều cần CPU xử lý.

Khi mức sử dụng CPU đạt 100%, điều đó có nghĩa là bộ não của máy chủ đang hoạt động hết công suất. Nó không còn tài nguyên trống để xử lý thêm bất kỳ yêu cầu nào nữa. Đây là lúc các vấn đề bắt đầu xuất hiện.

Dấu hiệu nhận biết VPS bị quá tải CPU:

  • Website tải chậm hoặc báo lỗi: Đây là dấu hiệu rõ ràng nhất. Người dùng có thể gặp lỗi 504 Gateway Timeout hoặc 503 Service Unavailable.
  • Không thể đăng nhập SSH: Phiên kết nối SSH của bạn có thể bị từ chối hoặc cực kỳ chậm chạp, gõ một lệnh và phải chờ rất lâu mới thấy phản hồi.
  • Bảng điều khiển (Control Panel) không phản hồi: Các công cụ quản lý như cPanel, DirectAdmin hoặc dashboard của nhà cung cấp cũng bị ảnh hưởng.
  • Các tác vụ định kỳ (Cron Jobs) thất bại: Các công việc tự động như backup, gửi email có thể không chạy đúng giờ hoặc không hoàn thành.

Nếu bạn đang gặp phải một hoặc nhiều triệu chứng trên, rất có thể CPU của bạn đang kêu cứu.

Quy trình chẩn đoán 3 bước “chuẩn bác sĩ”

Đối mặt với sự cố, việc hành động một cách có phương pháp sẽ giúp bạn tiết kiệm thời gian và tránh gây ra thêm lỗi. Hãy tuân theo quy trình 3 bước đơn giản sau:

  1. Bước 1: Bắt mạch – Xác định tiến trình gây lỗi:
    Giống như bác sĩ dùng ống nghe, chúng ta sẽ dùng công cụ dòng lệnh để “nghe” xem tiến trình (process) nào đang “la hét” to nhất. Đây là bước quan trọng nhất để biết bạn đang đối mặt với cái gì.
  2. Bước 2: Chẩn đoán – Phân loại “nghi can”:
    Sau khi xác định được “thủ phạm”, chúng ta cần phân loại nó. Nó thuộc nhóm nào? Là ứng dụng của bạn (PHP, MySQL), một kẻ lạ mặt đáng ngờ (mã độc), hay là một vấn đề vô hình từ hạ tầng?
  3. Bước 3: Kê đơn – Áp dụng giải pháp tận gốc:
    Với chẩn đoán chính xác trong tay, chúng ta sẽ đi vào thực hiện các bước xử lý chuyên sâu, tương ứng với từng loại “nghi can” mà chúng tôi sẽ trình bày chi tiết ngay sau đây.

Bộ dụng cụ “bắt bệnh” CPU cho mọi cấp độ

Để thực hiện quy trình trên, bạn cần có bộ dụng cụ phù hợp. Dưới đây là những công cụ từ cơ bản đến nâng cao.

htop: “Camera an ninh” giám sát mọi hoạt động

htop là công cụ không thể thiếu. Nó là phiên bản cải tiến, trực quan và mạnh mẽ hơn nhiều so với lệnh top truyền thống. Nếu VPS của bạn chưa có, hãy cài đặt nó ngay:

# Đối với Ubuntu/Debian
sudo apt update && sudo apt install htop

# Đối với CentOS/RHEL
sudo yum install htop

Sau khi gõ lệnh htop và nhấn Enter, bạn sẽ thấy một giao diện đầy màu sắc. Đừng hoảng sợ, hãy tập trung vào các chức năng chính:

  • Sắp xếp theo CPU (Nhấn F6): Ngay khi mở, nhấn F6, dùng phím mũi tên chọn PERCENT_CPU, và nhấn Enter. “Thủ phạm” sẽ ngay lập tức lộ diện ở trên cùng.
  • Xem cấu trúc cây (Nhấn F5): Nếu bạn thấy nhiều tiến trình giống nhau (như php-fpm), nhấn F5 để xem dạng cây. Điều này giúp xác định tiến trình mẹ đang tạo ra các tiến trình con gây lỗi.
  • “Tiêu diệt” tiến trình (Nhấn F9): Chọn tiến trình mất kiểm soát và nhấn F9. Luôn thử 15 SIGTERM (yêu cầu tắt lịch sự) trước. Nếu không hiệu quả, mới dùng đến 9 SIGKILL (buộc dừng).

Công cụ chuyên dụng cho từng dịch vụ

Nếu htop chỉ ra thủ phạm là một dịch vụ quen thuộc (MySQL, PHP), hãy dùng công cụ của chính nó để “mổ xẻ” sâu hơn.

  • Với MySQL/MariaDB:
    Đăng nhập vào MySQL và chạy lệnh sau:

SHOW FULL PROCESSLIST;

Ví dụ output mẫu của lệnh SHOW FULL PROCESSLIST;:

+-------+------+-----------+--------+---------+-------+------------------+--------------------------+
| Id    | User | Host      | db     | Command | Time  | State            | Info                     |
+-------+------+-----------+--------+---------+-------+------------------+--------------------------+
| 102   | root | localhost | my_db  | Query   | 350   | Sending data     | SELECT * FROM big_table  |
| 103   | web  | localhost | my_db  | Sleep   | 10    |                  | NULL                     |
+-------+------+-----------+--------+---------+-------+------------------+--------------------------+

Hãy chú ý cột TimeInfo. Một truy vấn chạy hàng trăm giây chắc chắn là có vấn đề. Bạn có thể buộc dừng một truy vấn đang chạy quá lâu bằng lệnh:

KILL [ID_của_tiến_trình];

  • Với PHP-FPM:
    Kích hoạt “slowlog” của PHP-FPM là cách tốt nhất để tìm ra script nào đang gây chậm. Mở file cấu hình pool của bạn (thường là /etc/php/[version]/fpm/pool.d/www.conf) và đảm bảo các dòng sau được bật:

request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm-slow.log

Sau đó, khởi động lại PHP-FPM. Các script chạy quá 10 giây sẽ được ghi lại vào file log.

perf: “Kính hiển vi” dành cho lập trình viên

Đối với người dùng nâng cao hoặc lập trình viên, perf là công cụ phân tích hiệu năng đỉnh cao. Lệnh perf top không chỉ cho biết tiến trình nào chiếm CPU, mà còn chỉ ra chính xác hàm (function) nào bên trong mã nguồn đang tiêu tốn nhiều chu kỳ xử lý nhất. Đây là công cụ vô giá để tối ưu code ở mức độ chi tiết.

iotop: “Soi” tình trạng đọc/ghi đĩa (I/O)

Đôi khi, bạn thấy CPU cao nhưng thực chất vấn đề lại nằm ở việc chờ đợi ổ đĩa. Trạng thái này gọi là iowait. Một tiến trình có thể chiếm 100% một core CPU, nhưng phần lớn thời gian đó là để chờ ổ đĩa phản hồi. iotop là công cụ hoàn hảo để chẩn đoán tình huống này.

Để cài đặt, bạn sử dụng lệnh:

# Đối với Ubuntu/Debian
sudo apt install iotop

# Đối với CentOS/RHEL
sudo yum install iotop

Sau đó, chỉ cần chạy sudo iotop. Công cụ này sẽ liệt kê các tiến trình đang thực hiện việc đọc/ghi đĩa nhiều nhất. Nếu bạn thấy một tiến trình (ví dụ mysqld hoặc một tiến trình backup) liên tục đứng đầu trong iotop, thì vấn đề của bạn có thể là do I/O chứ không phải do năng lực xử lý của CPU.

iotop

Ảnh chụp màn hình minh họa giao diện iotop

Truy tìm “thủ phạm” – 3 nguyên nhân hàng đầu & giải pháp triệt để

Giờ là lúc vào phần chính: điều tra 3 “nghi can” hàng đầu.

Nghi can #1: Ứng dụng & mã nguồn không tối ưu

Đây là nguyên nhân phổ biến nhất, chiếm đến 80% các trường hợp. Vấn đề đến từ chính các ứng dụng hoặc website mà bạn đang chạy trên VPS.

  • Mô tả: Một đoạn mã viết tồi (vòng lặp vô hạn), một truy vấn CSDL phức tạp không được tối ưu, một plugin WordPress xung đột, hoặc lưu lượng truy cập tăng đột biến đều có thể dễ dàng chiếm trọn 100% CPU.
  • Hành động khắc phục:
    • Tối ưu cơ sở dữ liệu (Database):
      • Kích hoạt Slow Query Log: Tương tự PHP-FPM, hãy bật slow_query_log trong file cấu hình my.cnf của MySQL để ghi lại các truy vấn chậm.
      • Sử dụng EXPLAIN: “Index” (chỉ mục) giống như mục lục của cuốn sách. Dùng lệnh EXPLAIN trước một câu lệnh SELECT để xem CSDL có đang sử dụng chỉ mục hay không. Nếu cột Extra hiển thị Using filesort hoặc Using temporary, đó là dấu hiệu truy vấn không được tối ưu.
    • Đối với WordPress:
      • Vô hiệu hóa Plugin: Tạm thời vô hiệu hóa lần lượt các plugin, bắt đầu với những plugin cài đặt gần đây nhất, để xem mức sử dụng CPU có giảm không. Các plugin về bảo mật, backup, bài viết liên quan thường là thủ phạm.
      • Sử dụng Plugin Query Monitor: Cài đặt plugin này để xem chính xác plugin nào, theme nào, hoặc hàm nào đang thực thi các truy vấn CSDL chậm chạp trên mỗi trang.
      • Tối ưu WP-Cron: WP-Cron mặc định chạy trên mỗi lượt truy cập, có thể gây quá tải. Hãy vô hiệu hóa nó và tạo một cron job thực sự trên hệ thống để chạy định kỳ.

Nghi can #2: Mã độc đào Coin (Cryptojacking Malware)

Nếu tiến trình chiếm CPU có một cái tên lạ hoắc, ngẫu nhiên (ví dụ: kthreaddk, kinsing) và bạn không hề cài đặt nó, rất có thể VPS của bạn đã bị nhiễm mã độc.

  • Mô tả: Hacker bí mật cài đặt phần mềm đào tiền ảo (như Monero) trên máy chủ của bạn. Các phần mềm này được thiết kế để tận dụng 100% sức mạnh CPU, biến VPS của bạn thành một “nô lệ” kiếm tiền cho chúng.
  • Hành động khắc phục:
    • Quét mã độc với ClamAV:
      ClamAV là một công cụ quét virus mã nguồn mở mạnh mẽ.

      1. Cài đặt: sudo apt install clamav clamav-daemon
      2. Cập nhật dữ liệu (bắt buộc): sudo freshclam
      3. Thực hiện quét an toàn và hiệu quả:
        Lệnh quét toàn bộ thư mục gốc (/) có thể rất chậm và quét cả những hệ thống file ảo như /proc, /sys. Chúng ta sẽ tối ưu bằng cách loại trừ chúng.

CẢNH BÁO: Không bao giờ tự động xóa file bị phát hiện. Luôn di chuyển chúng vào thư mục cách ly để xem xét lại.

# Tạo thư mục cách ly an toàn
sudo mkdir /root/quarantine

# Chạy lệnh quét, loại trừ thư mục hệ thống, di chuyển file nhiễm và ghi log
sudo clamscan -r --infected --move=/root/quarantine --log=/var/log/clamscan.log --exclude-dir="^/proc|^/sys|^/dev" /

Việc thêm --exclude-dir giúp quá trình quét tập trung vào các khu vực thực sự chứa mã nguồn và dữ liệu, giúp tăng tốc độ và giảm thiểu cảnh báo không cần thiết.

Sau khi quét, hãy kiểm tra file log /var/log/clamscan.log và các file trong thư mục /root/quarantine để xác nhận chúng thực sự là mã độc trước khi xóa vĩnh viễn.

    • Phòng bệnh hơn chữa bệnh:
      • Cấu hình tường lửa (UFW): sudo ufw enable và chỉ mở các cổng cần thiết (sudo ufw allow ssh, sudo ufw allow 'Nginx Full').
      • Bảo mật SSH: Vô hiệu hóa đăng nhập bằng mật khẩu và chỉ dùng SSH key. Mở file /etc/ssh/sshd_config, sửa PasswordAuthentication no và khởi động lại dịch vụ SSH.
      • Cài đặt Fail2Ban: Công cụ này tự động chặn các IP cố gắng dò mật khẩu (brute-force) vào VPS của bạn. sudo apt install fail2ban.

Nghi can #3: “Hàng xóm ồn ào” (The Noisy Neighbor)

Bạn đã tối ưu ứng dụng, quét sạch mã độc, nhưng CPU vẫn cao một cách bí ẩn? Vấn đề có thể không nằm ở bạn, đặc biệt là khi dùng VPS giá rẻ.

  • Mô tả: Trong môi trường ảo hóa chia sẻ, nhiều tài khoản VPS cùng chạy trên một máy chủ vật lý. Nếu một VPS “hàng xóm” chạy quá tải, nó có thể “lấn” sang tài nguyên CPU của bạn.
  • Hành động chẩn đoán:
    Mở htop và nhìn vào thanh trạng thái CPU ở trên cùng. Tìm mục st (viết tắt của Steal Time). Đây là tỷ lệ % thời gian CPU đáng lẽ của bạn nhưng bị “đánh cắp” bởi một máy ảo khác.
    Nếu chỉ số st này thường xuyên ở mức cao (trên 5-10%), chắc chắn bạn là nạn nhân của “hàng xóm ồn ào”.
  • Hành động khắc phục:
    Đây là lỗi của nhà cung cấp. Hãy chụp màn hình htop có chỉ số st cao, ghi lại thời gian xảy ra sự cố và gửi yêu cầu hỗ trợ đến họ. Một nhà cung cấp uy tín sẽ phải thừa nhận vấn đề và chuyển VPS của bạn sang một máy chủ vật lý (node) khác ít tải hơn.

Chủ động phòng ngừa – Giám sát và tối ưu hóa

Chữa bệnh rất tốn công, vì vậy hãy chủ động phòng bệnh. Thiết lập một hệ thống giám sát sẽ cảnh báo bạn về các vấn đề tiềm ẩn trước khi chúng trở nên nghiêm trọng.

  • Sử dụng các công cụ giám sát: Cài đặt các công cụ như Netdata, Zabbix, hoặc Prometheus để có các biểu đồ trực quan về việc sử dụng tài nguyên theo thời gian.
  • Viết Script cảnh báo đơn giản: Bạn có thể tạo một cron job chạy mỗi 5 phút để kiểm tra mức sử dụng CPU. Nếu vượt quá 90%, nó sẽ gửi email cảnh báo cho bạn.
  • Thường xuyên cập nhật hệ thống: Luôn chạy sudo apt update && sudo apt upgrade (hoặc tương đương) ít nhất một lần mỗi tuần để vá các lỗ hổng bảo mật.
  • Xem lại log thường xuyên: Dành thời gian để kiểm tra các file log trong /var/log. Chúng chứa rất nhiều thông tin giá trị về sức khỏe của hệ thống.

Các kỹ thuật phòng ngừa và kiểm soát nâng cao

Phân bổ “lòng tốt” với nicerenice

Linux cho phép bạn thiết lập độ ưu tiên cho các tiến trình. Giá trị “niceness” càng cao (tối đa 19), độ ưu tiên càng thấp. Để chạy một tác vụ nền (như backup) mà không ảnh hưởng đến dịch vụ chính, hãy dùng lệnh nice:

nice -n 19 tar -czf backup.tar.gz /var/www/html

“Đeo rọ mõm” cho tiến trình bằng systemd

systemd cho phép bạn giới hạn cứng tài nguyên cho một dịch vụ. Bằng cách thêm dòng CPUQuota=20% vào file .service của một ứng dụng, bạn có thể đảm bảo nó không bao giờ được sử dụng quá 20% tổng CPU.

Câu hỏi thường gặp (FAQ)

  1. Reboot VPS có giải quyết dứt điểm vấn đề 100% CPU không?
    Không. Reboot chỉ là giải pháp tạm thời. Nó giống như việc khởi động lại một chiếc máy tính bị treo. Nếu nguyên nhân gốc (code lỗi, mã độc) không được xử lý, vấn đề sẽ quay trở lại ngay khi tiến trình đó được khởi động lại.
  2. Chỉ số Steal Time (st) của tôi là 2-3%, có đáng lo ngại không?
    Một chỉ số st nhỏ và không liên tục có thể chấp nhận được trong môi trường ảo hóa. Tuy nhiên, nếu nó thường xuyên duy trì ở mức trên 5% và xảy ra đồng thời với việc VPS bị chậm, bạn nên liên hệ nhà cung cấp.
  3. Làm thế nào để chạy một tác vụ nặng mà không làm VPS bị treo?
    Sử dụng lệnh nice với giá trị cao (ví dụ nice -n 19) để giảm độ ưu tiên của tác vụ đó. Điều này sẽ ra lệnh cho hệ điều hành chỉ thực hiện tác vụ đó khi CPU có tài nguyên rảnh rỗi, ưu tiên cho các dịch vụ quan trọng hơn như web server.
  4. Tôi không phải lập trình viên, làm sao để yêu cầu người khác sửa “slow query”?
    Hãy kích hoạt “slow query log” của MySQL, để nó chạy trong một ngày. Sau đó, nén file log đó lại và gửi cho lập trình viên của bạn với yêu cầu “Vui lòng xem xét và tối ưu các truy vấn trong file log này”. File log đó là bằng chứng chính xác và giá trị nhất.

Kết luận

Tình trạng VPS 100% CPU tuy rất khó chịu nhưng gần như luôn có thể được giải quyết thông qua một quy trình chẩn đoán có phương pháp. Đừng hoảng sợ và reboot vội vàng. Hãy bình tĩnh, hành động như một thám tử: bắt đầu bằng htop để xác định “thủ phạm”, sau đó tuần tự điều tra 3 “nghi can” chính: mã nguồn ứng dụng, mã độc, và chất lượng hạ tầng của nhà cung cấp.

Việc làm chủ được các kỹ năng này không chỉ giúp bạn có một máy chủ ổn định, đáng tin cậy mà còn nâng cao đáng kể năng lực quản trị hệ thống của bạn.

Tuy nhiên, nếu bạn thường xuyên phải đối mặt với vấn đề “hàng xóm ồn ào” (Steal Time cao), đó là dấu hiệu rõ ràng nhất cho thấy gói VPS giá rẻ của bạn không còn đáp ứng được. Đã đến lúc xem xét việc đầu tư vào một nhà cung cấp dịch vụ chất lượng hơn hoặc một gói VPS cao cấp hơn để đảm bảo sự ổn định cho dự án của bạn.

Đây chỉ là một trong những sự cố phổ biến khi sử dụng VPS. Để tìm hiểu tổng quan về các vấn đề khác và cách khắc phục nhanh, hãy tham khảo bài viết chính của chúng tôi: Lỗi VPS giá rẻ: 6 vấn đề “chí mạng” và hướng dẫn sửa nhanh – VPS Chính hãng

Tài liệu tham khảo

  1. htop Official GitHub Repository: https://github.com/htop-dev/htop
  2. Linux Programmer’s Manual – htop(1): https://man7.org/linux/man-pages/man1/htop.1.html
  3. Linux Programmer’s Manual – iotop(8): https://man7.org/linux/man-pages/man8/iotop.8.html
  4. MySQL EXPLAIN Statement: https://dev.mysql.com/doc/refman/8.0/en/explain.html
  5. ClamAV Official Documentation – clamscan: https://docs.clamav.net/manual/Usage/Scanning.html
  6. Fail2Ban Official Website: https://www.fail2ban.org/
  7. systemd.resource-control Configuration: https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html
  8. Red Hat Enterprise Linux 7: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index