Nguyên Nhân và Khắc Phục VPS Full Tài Nguyên – Full CPU, RAM & Disk

VPS full tài nguyên là tình huống mọi quản trị viên đều gặp ít nhất một lần: website phản hồi chậm, SSH bị đơ, khách hàng phản ánh không truy cập được. Lúc này bạn cần xác định ngay thủ phạm là CPU, RAM hay Disk – rồi xử lý đúng chỗ thay vì khởi động lại máy chủ ảo VPS và hy vọng. Bài viết này của InterData đưa ra từng lệnh kiểm tra, cách đọc output và hướng khắc phục cụ thể để bạn tự xử lý ngay trên terminal.

Checklist kiểm tra nhanh VPS full tài nguyên trong 5 phút

Khi VPS bị chậm hoặc không phản hồi, việc đầu tiên là SSH vào server và chạy 3 lệnh dưới đây. Trong vòng 5 phút, bạn sẽ biết chính xác tài nguyên nào đang full – CPU, RAM hay Disk – để tập trung xử lý đúng chỗ thay vì mò mẫm.

Tài nguyên	Lệnh kiểm tra	Dấu hiệu full	Ý nghĩa output
CPU	top -bn1 | head -5	%Cpu(s) > 90%, load average > số core	Dòng %Cpu(s) cho thấy phần trăm CPU đang dùng. load average 3 số (1 phút, 5 phút, 15 phút) – nếu vượt số core VPS là quá tải.
RAM	free -h	Cột available còn dưới 100 MB	Nhìn dòng Mem, cột available (không phải free). Đây là lượng RAM thực sự còn dùng được, đã tính cả phần cache có thể giải phóng.
Disk	df -h	Phân vùng / hoặc /home đạt 90–100% Use%	Cột Use% cho thấy phần trăm ổ cứng đã dùng. Phân vùng gốc / trên 90% là cần dọn ngay.

Nếu bạn chưa quen với các lệnh Linux cơ bản, hãy mở bài đó song song để tra cứu nhanh cú pháp.

Đọc nhanh kết quả: Nếu CPU vượt 90% → chuyển đến phần Full CPU. Nếu RAM available dưới 100 MB → chuyển đến phần Full RAM. Nếu Disk trên 90% → chuyển đến phần Full Disk. Nhiều tài nguyên cùng full? Xử lý Disk trước (vì Disk đầy có thể khiến log không ghi được, database crash, kéo theo CPU và RAM tăng theo).

VPS full CPU – kiểm tra bằng top, htop và cách khắc phục

CPU chạm 100% khiến mọi request xử lý chậm, SSH lag từng ký tự, website trả lỗi 502 hoặc 504. Nguyên nhân thường gặp: PHP-FPM spawn quá nhiều worker, MySQL chạy query nặng không có index, crontab chạy trùng lặp, hoặc tệ nhất – malware đào coin chiếm trọn CPU. Để đi sâu hơn, bạn có thể tham khảo bài xử lý tình trạng bị full CPU trên VPS.

Kiểm tra CPU VPS bằng lệnh top và htop

Chạy lệnh top để xem process nào đang ngốn CPU nhiều nhất:

top

Trong giao diện top, nhấn Shift + P để sắp xếp theo %CPU giảm dần. Chú ý dòng đầu tiên hiển thị load average – đây là 3 con số cho thấy mức tải trung bình trong 1, 5 và 15 phút. Nếu VPS có 2 core mà load average là 4.5, CPU đang quá tải gấp đôi.

Nếu đã cài htop (cài bằng apt install htop trên Ubuntu/Debian hoặc yum install htop trên CentOS), bạn sẽ thấy giao diện trực quan hơn với thanh màu cho từng core CPU. Thanh đỏ chiếm hết thanh = core đó đang bị chiếm trọn.

Để xem nhanh 10 process chiếm CPU cao nhất mà không cần mở giao diện tương tác:

ps aux --sort=-%cpu | head -11

Cột %CPU cho thấy phần trăm CPU mỗi process đang dùng. Cột COMMAND cho biết process đó là gì – từ đây bạn xác định thủ phạm.

Nguyên nhân phổ biến và cách khắc phục VPS full CPU

PHP-FPM chiếm CPU cao: Thường do website WordPress chạy plugin nặng, theme không tối ưu hoặc bị brute-force login. Kiểm tra số lượng worker PHP-FPM đang chạy:

ps aux | grep php-fpm | wc -l

Nếu số worker cao hơn nhiều so với cấu hình pm.max_children, PHP-FPM đang spawn quá mức. Giảm pm.max_children trong file /etc/php/8.x/fpm/pool.d/www.conf (Ubuntu) hoặc /etc/php-fpm.d/www.conf (CentOS) cho phù hợp với RAM. Công thức tham khảo: pm.max_children = RAM khả dụng (MB) / RAM trung bình mỗi worker (MB). Với VPS 2 GB RAM, thường đặt 6–10 worker là hợp lý.

MySQL query nặng: Chạy lệnh sau trong MySQL CLI để xem query nào đang chạy lâu:

mysqladmin processlist

Hoặc đăng nhập MySQL rồi chạy SHOW FULL PROCESSLIST;. Query có cột Time lớn (hàng chục giây trở lên) và State là “Sending data” hoặc “Copying to tmp table” là dấu hiệu query không có index. Thêm index cho cột WHERE/JOIN sẽ giảm CPU đáng kể.

Crontab chạy trùng lặp: Kiểm tra crontab của tất cả user:

for user in $(cut -f1 -d: /etc/passwd); do echo "--- $user ---"; crontab -u $user -l 2>/dev/null; done

Nếu thấy nhiều job giống nhau chạy mỗi phút hoặc chồng chéo, bạn đã tìm ra nguyên nhân. Xóa các job trùng bằng crontab -e.

Malware/Cryptominer: Process lạ tên ngẫu nhiên (ví dụ: kdevtmpfsi, kinsing, xmrig) chiếm 100% CPU là dấu hiệu máy bị cài mã độc đào coin. Kill process đó:

kill -9 <PID>

Cảnh báo: kill -9 buộc dừng process ngay lập tức, không cho nó dọn dẹp. Chỉ dùng khi kill <PID> thông thường không có tác dụng. Với malware, sau khi kill cần kiểm tra crontab, /tmp, /var/tmp để xóa file nguồn, đổi password root và rà soát SSH key lạ trong ~/.ssh/authorized_keys.

Nếu VPS liên tục bị lag sau khi đã xử lý CPU, tham khảo thêm bài cách khắc phục VPS bị lag để kiểm tra các nguyên nhân khác như Disk I/O và network.

VPS full RAM – phân biệt RAM thật sự hết hay chỉ là cache

Rất nhiều người thấy output lệnh free -h hiển thị cột free gần bằng 0 rồi hoảng – nhưng thực tế VPS vẫn còn RAM dùng được. Linux dùng RAM trống để cache dữ liệu đọc từ Disk, tăng hiệu năng. Phần cache này sẽ tự giải phóng khi ứng dụng cần. Vì vậy, con số quan trọng nhất là cột available, không phải free.

Đọc đúng output lệnh free -h trên VPS

free -h

Output mẫu:

Cột	Ý nghĩa
total	Tổng RAM vật lý VPS được cấp.
used	RAM đang được ứng dụng sử dụng (bao gồm cả buff/cache trên kernel cũ).
free	RAM hoàn toàn trống, chưa được dùng cho bất kỳ thứ gì. Con số này thấp là bình thường.
buff/cache	RAM dùng cho buffer và cache – có thể giải phóng ngay khi ứng dụng cần.
available	Con số bạn cần nhìn. Là RAM thực sự có thể dùng ngay = free + phần cache giải phóng được.

Trong ví dụ trên: free chỉ còn 1.4Gi nhưng available vẫn còn 11Gi. VPS này còn dư rất nhiều dung lượng RAM. Nếu available dưới 100 MB – lúc đó mới là full RAM thật sự.

OOM Killer là gì và khi nào nó tự kill process?

Khi RAM và Swap đều cạn kiệt, kernel Linux kích hoạt OOM Killer (Out of Memory Killer) – tự động kill process chiếm nhiều RAM nhất để giữ hệ thống không crash hoàn toàn. MySQL và PHP-FPM thường là nạn nhân đầu tiên vì chúng chiếm nhiều bộ nhớ.

Kiểm tra xem OOM Killer đã từng hoạt động chưa:

# Ubuntu/Debian
dmesg | grep -i "oom-killer"

# Hoặc kiểm tra qua journalctl
journalctl -k | grep -i "oom"

Nếu thấy dòng kiểu Out of memory: Killed process 1234 (mysqld) – MySQL đã bị OOM Killer hạ. Đây là lý do website sập mà restart lại chạy bình thường, rồi vài giờ sau lại sập.

Với kết quả trong ảnh thì hiện chưa thấy dấu hiệu VPS đã bị OOM Killer xử lý tiến trình. Khi chạy 2 lệnh đều không trả về kết quả, nên kernel log hiện không ghi nhận sự kiện OOM theo các từ khóa đó.

Nguyên nhân phổ biến và cách khắc phục VPS full RAM

MySQL/MariaDB chiếm quá nhiều RAM: Tham số innodb_buffer_pool_size mặc định có thể quá lớn so với VPS nhỏ. Với VPS 2 GB RAM, đặt khoảng 256 MB–512 MB là hợp lý. Chỉnh trong /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu) hoặc /etc/my.cnf (CentOS):

innodb_buffer_pool_size = 256M

Restart MySQL sau khi chỉnh: systemctl restart mysql (hoặc mariadb).

PHP-FPM pm.max_children quá cao: Mỗi worker PHP-FPM chiếm 30–80 MB RAM tùy ứng dụng. 20 worker trên VPS 2 GB sẽ ngốn hết RAM. Xem RAM trung bình mỗi worker:

ps -ylC php-fpm --sort:rss | awk '{sum+=$8; n++} END {print sum/n/1024 " MB"}'

Lấy kết quả chia cho RAM khả dụng để tính số worker phù hợp, rồi chỉnh pm.max_children tương ứng.

Thiếu hoặc hết Swap: Swap đóng vai trò bộ nhớ dự phòng khi RAM vật lý đầy. Nếu VPS chưa có Swap hoặc Swap quá nhỏ, OOM Killer sẽ kích hoạt nhanh hơn. Tìm hiểu cách tạo và cấu hình trong bài Swap Memory là gì – bao gồm cách tạo swap file, chọn kích thước phù hợp và điều chỉnh swappiness.

Xem process nào chiếm nhiều RAM nhất:

ps aux --sort=-%mem | head -11

Cột %MEM cho thấy phần trăm RAM mỗi process chiếm. Cột RSS là RAM vật lý thật sự đang dùng (tính bằng KB).

VPS full Disk – tìm và dọn file chiếm dung lượng

VPS hết dung lượng ổ cứng gây ra hậu quả nặng: database không ghi được dữ liệu mới (MySQL crash), website không upload được file, log không ghi được khiến khó debug, thậm chí hệ điều hành không thể tạo process mới. Đây là loại full tài nguyên nguy hiểm nhất vì ảnh hưởng dây chuyền.

Kiểm tra dung lượng VPS bằng lệnh df và du

Bước 1 – xem tổng quan dung lượng từng phân vùng:

df -h

Tìm dòng có Mounted on là / (phân vùng gốc). Nếu cột Use% trên 90% – cần dọn ngay. Nếu đạt 100%, một số dịch vụ có thể đã ngừng hoạt động.

Bước 2 – tìm thư mục nào chiếm nhiều nhất:

du -sh /* 2>/dev/null | sort -rh | head -10

Lệnh này liệt kê 10 thư mục cấp 1 lớn nhất. Thường thủ phạm nằm trong /var (log, database), /home (website, backup) hoặc /tmp (file tạm).

Bước 3 – đào sâu vào thư mục lớn:

du -sh /var/* 2>/dev/null | sort -rh | head -10
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

Nếu cài ncdu (apt install ncdu hoặc yum install ncdu), bạn có giao diện duyệt thư mục trực quan hơn:

ncdu /

Nguyên nhân phổ biến và cách dọn VPS full ổ cứng

Log file phình to trong /var/log: Đây là nguyên nhân số 1. Các file như syslog, auth.log, nginx/access.log, nginx/error.log, mysql/error.log có thể phình lên hàng GB nếu không được rotate.

Kiểm tra kích thước log:

du -sh /var/log/* | sort -rh | head -10

Dọn log an toàn – dùng truncate thay vì rm để không làm mất file descriptor mà service đang giữ:

# Truncate log về 0 byte (file vẫn tồn tại, service không bị lỗi)
truncate -s 0 /var/log/nginx/access.log
truncate -s 0 /var/log/nginx/error.log

# Sau đó reload Nginx để ghi log mới
systemctl reload nginx

Cảnh báo: Dùng rm xóa file log mà service đang mở sẽ không giải phóng dung lượng ngay – dung lượng chỉ giải phóng khi service đó restart hoặc đóng file. Dùng truncate an toàn hơn.

Database binlog (MySQL/MariaDB): Binary log dùng cho replication, nhưng nếu không dùng replica mà quên tắt, binlog sẽ tích lũy hàng chục GB.

# Kiểm tra kích thước binlog
du -sh /var/lib/mysql/binlog*
# Hoặc
ls -lh /var/lib/mysql/mysql-bin.*

Nếu không dùng replication, xóa binlog cũ an toàn trong MySQL CLI:

PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 DAY;

Và tắt binlog bằng cách thêm skip-log-bin vào file cấu hình MySQL, rồi restart.

Backup cũ, file tạm, mail queue: Kiểm tra các vị trí thường bị bỏ quên:

# File tạm
du -sh /tmp /var/tmp

# Backup cũ trong home
find /home -name "*.tar.gz" -o -name "*.zip" -o -name "*.sql.gz" | xargs ls -lh 2>/dev/null

# Mail queue (nếu có MTA)
find /var/spool/mail -type f | xargs du -sh 2>/dev/null

Cảnh báo trước khi xóa: Luôn kiểm tra nội dung file/thư mục trước khi xóa. Không chạy rm -rf mà không chắc chắn mình đang xóa đúng thứ. Backup dữ liệu quan trọng ra ngoài VPS trước – copy sang máy local hoặc upload lên storage khác.

Phòng ngừa VPS full tài nguyên – giám sát và tự động dọn dẹp

Xử lý xong sự cố mà không thiết lập phòng ngừa thì chỉ là chờ lần full tiếp theo. Ba việc dưới đây giúp bạn phát hiện sớm và tự động xử lý trước khi VPS bị ảnh hưởng.

Cài Netdata – giám sát CPU, RAM, Disk theo thời gian thực

Netdata là công cụ monitoring miễn phí, giao diện web trực quan, hiển thị CPU, RAM, Disk, Network, process theo thời gian thực. Cài trong 1 lệnh:

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh

Sau khi cài, truy cập http://IP-VPS:19999 để xem dashboard. Netdata hỗ trợ cảnh báo qua email, Slack, Telegram khi CPU vượt 90%, RAM dưới 100 MB available, hoặc Disk trên 85%. Cấu hình cảnh báo trong /etc/netdata/health.d/.

Bạn cũng có thể chạy benchmark kiểm tra hiệu năng VPS định kỳ để phát hiện sớm khi phần cứng bắt đầu xuống cấp so với thông số ban đầu.

Thiết lập logrotate – tự động xoay log, tránh full Disk

logrotate có sẵn trên hầu hết distro Linux. Kiểm tra cấu hình mặc định:

cat /etc/logrotate.d/nginx

Nếu chưa có hoặc cần tùy chỉnh, tạo file cấu hình cho ứng dụng:

# Tạo file /etc/logrotate.d/custom-app
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
}

Cấu hình này giữ log 7 ngày, nén log cũ bằng gzip, bỏ qua nếu file log không tồn tại. Chạy thử để kiểm tra cấu hình:

logrotate -d /etc/logrotate.d/custom-app

Crontab dọn file tạm tự động

Thêm cronjob dọn file tạm cũ hơn 7 ngày trong /tmp:

# Mở crontab root
crontab -e

Nếu đây là lần đầu bạn thiết lập crontab thì hệ thống sẽ yêu cầu chọn crontab editor. Lúc này hãy nhập “1” để sử dụng Nano – đây cũng là trình chỉnh sửa crontab đơn giản nhất.

# Thêm dòng sau vào file crontab (chạy mỗi ngày lúc 3 giờ sáng)
0 3 * * * find /tmp -type f -atime +7 -delete 2>/dev/null

Cảnh báo: Không dọn tự động các thư mục như /var/log hay /home bằng crontab – dùng logrotate cho log, backup policy cho file website. Crontab + find -delete chỉ phù hợp với file tạm thật sự.

Để tìm hiểu thêm các phương pháp tối ưu VPS toàn diện – từ kernel tuning, cache, CDN đến tối ưu database – tham khảo bài hướng dẫn chi tiết.

Đã tối ưu hết mà VPS vẫn full tài nguyên – khi nào nên nâng cấp?

Nếu bạn đã thực hiện đủ các bước tối ưu ở trên – giảm worker, tune MySQL, dọn log, thiết lập monitoring – mà CPU, RAM hoặc Disk vẫn chạm ngưỡng trong giờ cao điểm, vấn đề không còn ở cấu hình. Workload đã vượt quá khả năng gói VPS hiện tại.

Lúc này bạn có hai lựa chọn: nâng cấp gói VPS lớn hơn, hoặc chuyển sang Cloud Server. Bảng dưới đây so sánh theo từng tiêu chí cụ thể:

Tiêu chí	Nâng gói VPS	Chuyển sang Cloud Server
Tải ổn định, dự đoán được	Phù hợp – chọn gói có CPU/RAM cao hơn 1 bậc.	Được, nhưng chi phí có thể cao hơn cho tải ổn định.
Tải biến động theo giờ/mùa	Phải chọn gói đủ cho peak → lãng phí lúc thấp điểm.	Phù hợp – nâng/hạ CPU, RAM theo tải thực tế, không lãng phí.
Chạy nhiều service nặng đồng thời	Bị giới hạn bởi gói cố định.	Phù hợp – tài nguyên phân bổ theo nhu cầu thực tế.
Nâng cấp tài nguyên	Cần migrate sang gói mới, có thể downtime ngắn.	Nâng/hạ nhanh qua panel, không cần migrate.
Chi phí khởi điểm	Thường thấp hơn với cùng tài nguyên.	Cao hơn VPS cơ bản, nhưng linh hoạt hơn khi tải thay đổi.

Quy tắc ra quyết định: Nếu traffic ổn định và bạn chỉ cần thêm 1–2 core hoặc gấp đôi RAM → nâng gói VPS. Nếu traffic tăng đột biến theo chiến dịch marketing, flash sale, hoặc bạn chạy nhiều ứng dụng Docker cùng lúc → Cloud Server cho phép co giãn tài nguyên theo tải mà không cần dừng server.

Nội dung mang tính tham khảo kỹ thuật. Lệnh, cấu hình và cách xử lý có thể khác nhau tùy hệ điều hành (Ubuntu, Debian, CentOS, AlmaLinux…), phiên bản phần mềm (MySQL 5.7/8.0, MariaDB 10.x, PHP 7.4/8.x, Nginx/Apache…) và môi trường thực tế của từng server. Luôn backup dữ liệu trước khi thao tác trên server production. InterData không chịu trách nhiệm cho các thay đổi cấu hình do người dùng tự thực hiện.