VPS tự khởi động lại hoặc bị treo: Nguyên nhân và cách xử lý

VPS tự động khởi động lại hoặc bị treo đột ngột là một trong những vấn đề khó chẩn đoán nhất mà admin gặp phải. Nguyên nhân chính là khi VPS crash hay bị treo, hệ thống mất đi khả năng ghi log, khiến việc tìm ra nguyên nhân trở nên phức tạp. Khác với các lỗi thông thường có thể debug qua file log, vấn đề này yêu cầu cách tiếp cận khác để phát hiện dấu vết.

Bài viết này sẽ hướng dẫn bạn cách xác định nguyên nhân VPS tự khởi động lại thông qua việc phân tích log hệ thống, kiểm tra các nguyên nhân phổ biến và áp dụng các biện pháp phòng ngừa hiệu quả.

Lưu ý: Các lệnh cung cấp trong bài là ví dụ, với các lệnh thao tác đến process hoặc tập tin, hãy tìm hiểu kỹ trước khi thao tác.

Kiểm tra lịch sử khởi động lại

ℹ️ Việc xác định đúng thời điểm VPS bị reboot sẽ giúp bạn tìm ra pattern và nguyên nhân gây ra vấn đề

Bước đầu tiên là xác định thời điểm và tần suất VPS bị khởi động lại. Sử dụng các lệnh sau để kiểm tra:

Xem lịch sử reboot

# Hiển thị tất cả lần reboot gần nhất
last reboot
# Kiểm tra thời gian uptime hiện tại
uptime
# Xem thời điểm boot gần nhất
who -b

Ví dụ output từ lệnh last reboot:

reboot   system boot  5.4.0-74-generic Tue Mar 21 15:42 - 23:15  (07:32)
reboot   system boot  5.4.0-74-generic Tue Mar 21 09:15 - 15:41  (06:26)
reboot   system boot  5.4.0-74-generic Mon Mar 20 18:30 - 09:14  (14:44)

⚠️ Nếu thấy VPS reboot nhiều lần trong ngày hoặc có pattern thời gian đặc biệt (ví dụ cứ vào 3:00 sáng), đây là manh mối quan trọng để tìm nguyên nhân.

Đọc log hệ thống

Kiểm tra kernel messages

# Xem 50 dòng cuối của kernel messages với timestamp
dmesg -T | tail -50

# Tìm các thông báo lỗi quan trọng
dmesg -T | grep -i "error\|critical\|panic\|killed"

Phân tích journald logs

# Xem log từ lần boot trước (nếu journald được cấu hình persistent)
journalctl -b -1

# Xem log từ boot hiện tại
journalctl -b 0
# Tìm các message quan trọng
journalctl --priority=err --since "yesterday"

Kiểm tra syslog

# Tìm lỗi critical trong syslog
grep -i "error\|critical\|panic" /var/log/syslog | tail -20

# Kiểm tra auth log cho vấn đề bảo mật
grep -i "failed\|invalid" /var/log/auth.log | tail-10

Nguyên nhân 1: OOM Killer

Out of Memory Killer là nguyên nhân phổ biến khiến VPS bị treo hoặc khởi động lại khi hệ thống hết RAM. OOM Killer sẽ kill các process để giải phóng bộ nhớ, có thể làm crash toàn bộ hệ thống.

Cách kiểm tra

# Tìm dấu vết OOM Killer trong kernel messages
dmesg -T | grep "killed process"

# Hoặc kiểm tra trong syslog
grep -i oom /var/log/syslog
# Xem memory usage hiện tại
free -h
cat /proc/meminfo | grep -i "memavailable\|memfree"

Ví dụ log OOM Killer:

[Tue Mar 21 15:41:32 2023] Out of memory: Kill process 1234 (mysql) score 856 or sacrifice child
[Tue Mar 21 15:41:32 2023] Killed process 1234 (mysql) total-vm:2097152kB, anon-rss:1048576kB, file-rss:0kB

Giải pháp

1. Thêm swap space để mở rộng memory ảo:

# Tạo file swap 2GB
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Tự động mount swap khi boot
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

2. Giảm số lượng services đang chạy:

# Xem services tiêu thụ RAM nhiều
ps aux --sort=-%mem | head -10

# Disable các service không cần thiết
sudo systemctl disable nginx  # nếu chỉ cần Apache
sudo systemctl stop mysqld    # nếu không dùng database

3. Nâng cấp RAM VPS nếu workload thực sự cần nhiều memory hơn.

💡 Mẹo: Trước khi nâng cấp RAM, hãy kiểm tra xem có process nào memory leak hay không bằng lệnh top và quan sát trong vài ngày

Tham khảo: VPS hết RAM và Swap VPS

Nguyên nhân 2: Kernel panic

Kernel panic xảy ra khi kernel Linux gặp lỗi nghiêm trọng không thể phục hồi. Hệ thống sẽ dừng hoạt động hoặc tự khởi động lại.

Cách kiểm tra

# Tìm kernel panic trong logs
dmesg -T | grep -i "panic"
grep -i "kernel panic" /var/log/syslog

# Kiểm tra core dumps
ls -la /var/crash/

🚫 Cảnh báo: Kernel panic thường báo hiệu vấn đề nghiêm trọng về hardware hoặc driver. Cần xử lý ngay để tránh mất dữ liệu

Phòng ngừa và giám sát

Bật persistent journald logging

Mặc định, journald logs chỉ lưu trong RAM và mất đi khi reboot. Enable persistent logging để phân tích sau khi crash:

# Tạo folder lưu logs
sudo mkdir -p /var/log/journal

# Cấu hình journald persistent
sudo nano /etc/systemd/journald.conf

Thêm vào file cấu hình:

[Journal]
Storage=persistent
SystemMaxUse=500M  # Giới hạn dung lượng log

Kết luận

VPS tự khởi động lại có thể do nhiều nguyên nhân từ hết RAM, kernel panic, đến can thiệp của provider. Cách hiệu quả nhất là enable logging đầy đủ, sau đó phân tích log một cách có hệ thống để xác định nguyên nhân chính xác.

Việc phòng ngừa bằng cách monitor resource usage, cấu hình swap phù hợp và giữ hệ thống updated sẽ giảm thiểu đáng kể khả năng xảy ra vấn đề này.

Đăng ký VPS AZDIGI ngay để trải nghiệm dịch vụ VPS chất lượng cao với giá cả phải chăng.