VPS chậm: chẩn đoán CPU, RAM, disk và network

VPS chậm không luôn do gói cấu hình quá nhỏ. Truy vấn database, thiếu RAM, chờ storage, giới hạn CPU hoặc mạng bên ngoài đều có thể tạo cùng triệu chứng. Hãy đo ở đúng thời điểm lỗi trước khi restart hoặc nâng cấp.

Xác định 'chậm' ở bước nào

Ghi thời gian, endpoint, số người bị ảnh hưởng và trạng thái lỗi. So từ client bên ngoài với phép đo ngay trên VPS. Nếu request nội bộ nhanh nhưng từ khách chậm, hướng điều tra khác với ứng dụng chậm cả khi gọi local.

Bộ lệnh chỉ đọc ban đầu

uptime
free -h
df -h
df -i
vmstat 1 5
ps -eo pid,comm,%cpu,%mem --sort=-%cpu

Lệnh khả dụng phụ thuộc hệ điều hành và package. Chúng là ảnh chụp ngắn; lặp tại thời điểm có triệu chứng và kết hợp log. Không đăng công khai output chứa thông tin nhạy cảm hoặc đường dẫn không cần thiết.

CPU và load average

Load average không phải tỷ lệ CPU sử dụng; nó có thể phản ánh cả tác vụ chờ ở một số trạng thái. Kiểm tra user/system, thời gian chờ I/O và steal. Một process dùng hết một core có thể là nút thắt trong khi tổng CPU còn thấp.

Nếu có quota, CPU theo biểu đồ trong guest chưa phản ánh toàn bộ giới hạn. So chính sách VPS và số liệu nhà cung cấp trước khi kết luận noisy neighbor.

RAM và storage

Linux có thể dùng RAM cho cache; RAM 'free' thấp chưa đồng nghĩa thiếu bộ nhớ. Đối chiếu available, swap, OOM và hành vi ứng dụng. Nếu memory tăng liên tục sau mỗi request, điều tra leak trước khi chỉ tăng gói.

Storage cần kiểm tra latency, dung lượng và inode. Backup, import dữ liệu hoặc log lớn có thể cạnh tranh I/O. Nâng lên NVMe không tự sửa full disk, query quét quá nhiều dữ liệu hoặc ghi log không kiểm soát.

Mạng và phụ thuộc ngoài

• Thời gian DNS và kết nối TCP/TLS.
• Throughput đến đích ứng dụng cần dùng.
• Timeout/retry của API ngoài.
• Độ trễ database nếu ở máy khác.
• Kết quả từ nhiều khung giờ và mạng client.

Speed test tới node gần không chứng minh mọi kết nối quốc tế tốt. Đo endpoint thật; ping chỉ là tín hiệu bổ trợ vì ICMP có thể bị hạn chế. Retry dồn dập cũng có thể làm vấn đề ban đầu thành quá tải.

Thay đổi một yếu tố rồi kiểm tra lại

1. Lưu số liệu và baseline của lỗi.
2. Xác định bottleneck có bằng chứng.
3. Thử tối ưu query/cache/process trên môi trường phù hợp.
4. Nếu thiếu tài nguyên thực, thử gói hoặc máy khác.
5. So latency, error rate cùng tải trước và sau.
6. Ghi thay đổi, rollback và cảnh báo để phát hiện tái diễn.

Restart có thể tạm giảm tải nhưng làm mất bằng chứng và không xử lý nguyên nhân. Nếu khách đang gián đoạn, ưu tiên khôi phục có kiểm soát rồi tiếp tục điều tra với log đã giữ.

Xem Cloud VPS và khi nào chuyển dedicated. Gửi thời điểm lỗi, workload và metric đã đo để nhận hỗ trợ chính xác hơn mô tả 'server lag'.