❤️ AZDIGI chính thức cập nhật hệ thống blog mới hoàn chỉnh. Tuy nhiên có thể một số bài viết bị sai lệch hình ảnh, hãy ấn nút Báo cáo bài viết ở cuối bài để AZDIGI cập nhật trong thời gian nhanh nhất. Chân thành cám ơn.

VPS chạy chậm là vấn đề mà hầu hết admin đều gặp phải ít nhất một lần. Có thể là website load lâu, server phản hồi chậm, hoặc thậm chí VPS bị treo luôn. Nguyên nhân thì rất đa dạng: từ CPU quá tải, hết RAM, disk I/O nghẽn cổ chai, cho đến database MySQL chậm như sên.

Bài này tập hợp những lỗi hiệu năng VPS phổ biến nhất và cách khắc phục từng loại. Mình sẽ chia thành các nhóm rõ ràng, kèm lệnh chẩn đoán cụ thể để bạn tự check được. Mỗi phần có link đến bài hướng dẫn chi tiết để đào sâu hơn.

Đối tượng phù hợp: dev, admin, ai quản lý VPS và gặp tình trạng server chạy không mượt.

Chẩn đoán nhanh trong 60 giây

Cartoon doctor/mechanic examining VPS server performance with diagnostic tools

Trước khi đi vào từng loại lỗi, chạy nhanh mấy lệnh này để có cái nhìn tổng quan:

# Kiểm tra uptime và load averageuptime

Output mẫu:

 14:23:45 up 7 days, 2:15, 1 user, load average: 2.15, 1.89, 1.56

💡 Mẹo: Load average > số CPU cores là dấu hiệu server đang quá tải.

# Xem tiến trình đang chạy, CPU và RAM usagehtop

Quan sát cột %CPU và %MEM, process nào ngốn nhiều nhất.

# Kiểm tra RAM và swapfree -h

Output mẫu:

               total        used        free      shared  buff/cache   availableMem:           2.0Gi       1.3Gi       156Mi       24Mi       512Mi       512MiSwap:          1.0Gi       256Mi       768Mi

⚠️ Lưu ý: Nếu available RAM < 10% total RAM là có vấn đề.

# Xem disk I/Oiostat -x 1 3

Output mẫu:

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %utilsda              15.3    8.7     245.1     156.3     0.2      1.4   85.2

%util > 80% liên tục nghĩa là disk đang nghẽn.

Có kết quả các lệnh trên rồi, bây giờ đi vào từng loại lỗi cụ thể.

Lỗi CPU: khi processor bị quá tải

CPU chip with fire illustration showing overheating performance issue

Triệu chứng

  • Load average cao hơn số CPU cores
  • %CPU usage liên tục > 90%
  • Website phản hồi chậm hoặc timeout
  • SSH connect lâu hơn bình thường

Nguyên nhân thường gặp

CPU steal time cao: VPS shared resources bị neighbor ảnh hưởng. Check bằng lệnh:

sar -u 1 5

Output mẫu có vấn đề:

%user   %nice    %system   %iowait    %steal     %idle12.5     0.0      15.2       5.3       25.8      41.2

%steal > 10% là vấn đề về virtualization layer.

Process zombie hoặc runaway: Một process nào đó bị lỗi, loop vô tận và ngốn CPU. Dùng htop để spot process này.

Cron job chồng chéo: Nhiều script cron chạy cùng lúc mà chưa kết thúc job trước đó.

Khắc phục nhanh

Kill process ngốn CPU cao:

# Tìm process ID ngốn CPU nhấtps aux --sort=-%cpu | head -5# Kill process (thay PID tương ứng)kill -9 1234

Check cron job:

# Xem các cron job đang chạypgrep -f cronps aux | grep cron# Kiểm tra crontabcrontab -l

ℹ️ Chi tiết về khắc phục CPU cao: CPU VPS tăng cao 100%

Lỗi RAM: khi bộ nhớ cạn kiệt

RAM modules with overflow water drops showing memory problems

Triệu chứng

  • Available memory < 10% total RAM
  • Swap usage cao > 50%
  • OOM (Out of Memory) errors trong log
  • Kernel kill các process tự động

Nguyên nhân thường gặp

Memory leak: Application không giải phóng RAM sau khi xong task. Hay gặp với PHP scripts, Node.js apps viết không tốt.

Cache quá lớn: MySQL query cache, Redis cache, hoặc application cache chiếm hết RAM.

Too many processes: Apache/Nginx spawn quá nhiều worker processes cùng lúc.

Chẩn đoán chi tiết

# Xem process ngốn RAM nhấtps aux --sort=-%mem | head -10

Output mẫu:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDmysql     1234  2.1 35.2 356789 89123 ?      Sl   14:20   0:15 /usr/sbin/mysqldapache2   1235  0.5 12.4 123456 31456 ?      S    14:21   0:02 /usr/sbin/apache2
# Check swap usage detailcat /proc/swapsswapon -s

Khắc phục

Restart process ngốn RAM:

# Restart MySQL nếu nó ngốn RAM quá nhiềusystemctl restart mysql# Hoặc Apache/Nginxsystemctl restart apache2systemctl restart nginx

Tăng swap tạm thời (nếu chưa có):

# Tạo swap file 1GBdd if=/dev/zero of=/swapfile bs=1M count=1024chmod 600 /swapfilemkswap /swapfileswapon /swapfile

ℹ️ Chi tiết khắc phục: VPS hết RAMSwap VPS

Lỗi Disk: I/O nghẽn cổ chai

Hard disk with slow speedometer showing I/O bottleneck

Triệu chứng

  • iostat %util > 80% liên tục
  • iowait cao trong sar -u
  • Disk read/write slow, operations bị pending
  • MySQL query chậm do write/read disk

Nguyên nhân thường gặp

Ổ cứng đầy: Filesystem usage > 90%, không còn free space cho OS hoạt động.

Log files quá lớn: Access log, error log, MySQL binlog tích tụ không rotate.

Database không tối ưu: MySQL table scan, missing indexes, query chậm.

Disk hardware issue: Bad sectors, controller lỗi (ít gặp với VPS cloud).

Chẩn đoán

# Kiểm tra disk spacedf -h

Output mẫu có vấn đề:

Filesystem      Size  Used Avail Use% Mounted on/dev/sda1        20G   19G  512M  95% /
# Tìm thư mục lớn nhấtdu -h --max-depth=1 / | sort -rh | head -10# Chi tiết I/O per processiotop

Khắc phục

Xóa log cũ:

# Xóa log Apache/Nginx cũfind /var/log -name \"*.log\" -mtime +7 -delete# Clear log hiện tại mà không restart service> /var/log/apache2/access.log> /var/log/nginx/access.log

Clean MySQL binlog:

# Xem binlog đang cóls -lh /var/lib/mysql/mysql-bin.*# Xóa binlog cũ (giữ lại 3 ngày gần nhất)mysql -u root -p -e \"PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY);\"

ℹ️ Chi tiết: Disk I/O caoVPS đầy ổ cứng

Lỗi Database: MySQL chậm như sên

Triệu chứng

  • Website load lâu, đặc biệt dynamic pages
  • MySQL process list có nhiều query \”Sending data\” hoặc \”Copying to tmp table\”
  • Database connection timeout
  • CPU/RAM/Disk I/O của mysqld process cao

Nguyên nhân thường gặp

Missing indexes: Query scan toàn bộ table thay vì dùng index.

Slow query log đầy: Queries chạy quá lâu (> 2 seconds).

InnoDB buffer pool nhỏ: Không đủ RAM cache cho database.

Table lock contention: Nhiều queries cùng wait lock một table.

Chẩn đoán MySQL

# Xem process list hiện tạimysql -u root -p -e \"SHOW PROCESSLIST;\"

Output mẫu có vấn đề:

Id  User   Host      db    Command Time  State           Info123 web    localhost mydb  Query   45    Sending data    SELECT * FROM large_table WHERE...124 web    localhost mydb  Query   30    Copying to tmp  SELECT COUNT(*)...
# Enable slow query logmysql -u root -p -e \"SET GLOBAL slow_query_log = 'ON';\"mysql -u root -p -e \"SET GLOBAL long_query_time = 2;\"# Xem slow queriestail -f /var/log/mysql/slow.log

Khắc phục MySQL

Optimize queries bằng EXPLAIN:

-- Check execution planEXPLAIN SELECT * FROM users WHERE email = 'user@example.com';-- Thêm index cho column thường queryALTER TABLE users ADD INDEX idx_email (email);

Tune MySQL config trong /etc/mysql/my.cnf:

[mysqld]# Tăng InnoDB buffer pool (70% RAM)innodb_buffer_pool_size = 512M# Tăng query cachequery_cache_size = 64Mquery_cache_type = 1# Tăng connection poolmax_connections = 200
# Restart MySQL sau khi configsystemctl restart mysql

ℹ️ Chi tiết: MySQL chậm

Lỗi Web Server: Nginx/PHP-FPM nghẽn

Triệu chứng

  • HTTP response time cao > 5 seconds
  • 502 Bad Gateway errors
  • Nginx/Apache process ngốn CPU cao
  • PHP-FPM pool đầy, request queue pending

Nguyên nhân thường gặp

PHP-FPM pool size nhỏ: Không đủ worker processes xử lý concurrent requests.

PHP script chậm: Code không tối ưu, database queries chậm.

Nginx worker_processes thiết lập sai: Không match với số CPU cores.

File upload lớn: Client upload file lớn làm block worker processes.

Chẩn đoán Web Server

Check Nginx status:

# Xem error logtail -f /var/log/nginx/error.log# Check active connectionsnginx -s reload  # Test config first

Check PHP-FPM status:

# Xem pool status (nếu enable status page)curl http://localhost/php-fpm-status# Xem PHP-FPM logtail -f /var/log/php7.4-fpm.log

Tối ưu Nginx

File /etc/nginx/nginx.conf:

# Set worker processes = số CPU coresworker_processes auto;# Tăng worker connectionsevents {    worker_connections 1024;    use epoll;}http {    # Tăng buffer sizes    client_body_buffer_size 10K;    client_header_buffer_size 1k;    client_max_body_size 8m;    large_client_header_buffers 4 16k;        # Enable gzip compression    gzip on;    gzip_comp_level 6;    gzip_types text/plain text/css application/json application/javascript text/xml;}

Tối ưu PHP-FPM

File /etc/php/7.4/fpm/pool.d/www.conf:

[www]; Tăng số PM childrenpm = dynamicpm.max_children = 20pm.start_servers = 5pm.min_spare_servers = 2pm.max_spare_servers = 8; Enable slow logslowlog = /var/log/php7.4-fpm-slow.logrequest_slowlog_timeout = 5s; Tăng memory limitphp_admin_value[memory_limit] = 256M

Restart services:

systemctl restart nginxsystemctl restart php7.4-fpm

ℹ️ Chi tiết: Tối ưu Nginx PHP-FPM

Bảng tổng hợp: Triệu chứng → Nguyên nhân → Lệnh → Giải pháp

Triệu chứng Nguyên nhân có thể Lệnh chẩn đoán Bài chi tiết
Load average cao CPU quá tải uptime, htop CPU VPS tăng cao
Available RAM < 10% Memory leak, cache lớn free -h, ps aux --sort=-%mem VPS hết RAM
Swap usage > 50% Thiếu RAM, process ngốn memory swapon -s, cat /proc/swaps Swap VPS
%util disk > 80% I/O nghẽn, disk đầy iostat -x, df -h Disk I/O cao
Filesystem 95% full Log files lớn, cache đầy du -h --max-depth=1 / VPS đầy ổ cứng
MySQL query chậm Missing index, buffer pool nhỏ SHOW PROCESSLIST, EXPLAIN MySQL chậm
502 Bad Gateway PHP-FPM pool đầy tail -f /var/log/nginx/error.log Tối ưu Nginx PHP-FPM
Ping time > 100ms Network latency, routing issue ping, traceroute VPS chậm do mạng
WordPress admin chậm Plugin bloat, database không optimize Enable WP_DEBUG, check queries WordPress VPS chậm
VPS restart tự động OOM killer, kernel panic dmesg, /var/log/syslog VPS tự restart

Phòng ngừa: Giám sát để phát hiện sớm

Shield protecting server with monitoring dashboard for prevention

Thay vì chờ VPS chậm rồi mới troubleshoot, tốt hơn là setup monitoring để phát hiện vấn đề từ sớm.

Basic monitoring với tools có sẵn

Install htop và iotop:

apt updateapt install htop iotop sysstat

Enable sysstat để collect metrics:

systemctl enable sysstatsystemctl start sysstat

Xem metrics historical:

# CPU usage 24h quasar -u# Memory usage 24h qua  sar -r# Disk I/O 24h quasar -d

💡 Mẹo: Setup script monitoring tự động để phát hiện vấn đề sớm thay vì đợi VPS lag mới xử lý.

Khi nào nên nâng cấp VPS

Đôi khi optimize hết mức rồi mà VPS vẫn chậm, có thể do:

  • RAM không đủ cho workload: Application thực sự cần nhiều RAM hơn package hiện tại.
  • CPU cores ít: Multi-threaded applications cần nhiều cores để chạy song song.
  • Storage I/O limit: HDD cơ học không theo kịp, cần SSD hoặc NVMe.
  • Network bandwidth hạn chế: Site traffic cao cần bandwidth lớn hơn.

⚠️ Lưu ý: Trước khi nâng cấp, hãy optimize kỹ những gì đã có theo hướng dẫn ở trên. Nhiều khi vấn đề nằm ở config chứ không phải thiếu resources.

AZDIGI Pro VPS sử dụng SSD NVMe RAID-10 và CPU Intel Xeon mới nhất, giúp giải quyết được hầu hết vấn đề hiệu năng trên. Đặc biệt phù hợp cho:

  • Website traffic cao
  • Database-heavy applications
  • Multiple websites trên cùng VPS
  • Development environments cần resources ổn định

Hy vọng bài tổng hợp này giúp bạn nhanh chóng xác định và khắc phục được các vấn đề hiệu năng VPS. Save lại để reference khi cần, và nhớ check monitoring thường xuyên để phòng ngừa từ sớm.

Chia sẻ:
Bài viết đã được kiểm duyệt bởi AZDIGI Team

Về tác giả

Trần Thắng

Trần Thắng

Chuyên gia tại AZDIGI với nhiều năm kinh nghiệm trong lĩnh vực web hosting và quản trị hệ thống.

Hơn 10 năm phục vụ 80.000+ khách hàng

Bắt đầu dự án web của bạn với AZDIGI