Tại sao đừng bao giờ tin vào thông số quảng cáo?
Hãy tưởng tượng kịch bản này: 2 giờ sáng, điện thoại rung liên hồi vì ứng dụng web chậm như rùa. Dashboard Proxmox vẫn báo CPU/RAM xanh ngắt, nhưng thực tế người dùng đang kêu trời. Thủ phạm thường nằm ở những góc khuất như I/O Wait hoặc nghẽn cổ chai card mạng ảo hóa.
Kinh nghiệm thực chiến cho thấy việc tin vào cấu hình mặc định của nhà cung cấp VPS là một sai lầm lớn. Trong homelab của mình với 12 VM, mình luôn benchmark mọi thứ trước khi cài Database. Ảo hóa luôn đi kèm với “Virtualization Overhead”. Nếu không đo đạc, bạn sẽ không biết mình đang lãng phí bao nhiêu % sức mạnh phần cứng vào tay Hypervisor.
Bộ công cụ benchmark “nhập môn”
Để đánh giá toàn diện, chúng ta sẽ sử dụng bộ ba công cụ tiêu chuẩn sau:
- sysbench: Kiểm tra khả năng tính toán của CPU và tốc độ RAM.
- fio: Tiêu chuẩn vàng để đo Disk I/O. Đừng dùng
dd, nó chỉ đo được bề nổi của tảng băng. - iperf3: Đo băng thông thực tế giữa các VM hoặc từ VM ra Host.
Cài đặt nhanh trên Ubuntu/Debian:
sudo apt update && sudo apt install fio sysbench iperf3 -yVới CentOS/RHEL, bạn cần cài EPEL trước:
sudo yum install epel-release -y && sudo yum install fio sysbench iperf3 -y1. Đo sức mạnh CPU: Tránh tình trạng “hàng xóm ồn ào”
Trong môi trường ảo hóa, tài nguyên CPU thường bị chia sẻ (overcommit). Nếu một VM khác trên cùng node đang chạy tác vụ nặng, hiệu suất của bạn sẽ sụt giảm ngay lập tức.
Lệnh dưới đây sẽ yêu cầu CPU tính toán số nguyên tố để kiểm tra độ ổn định:
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) runHãy chú ý mục events per second. Một ví dụ thực tế: Khi mình đổi CPU Type từ kvm64 sang host trong Proxmox, chỉ số này tăng tới 15-20%. Chế độ host cho phép VM tận dụng toàn bộ tập lệnh (như AES-NI, AVX) của CPU vật lý.
2. Hiệu suất ổ cứng: IOPS mới là con số quyết định
Các ứng dụng như MySQL hay PostgreSQL không đọc ghi tuần tự. Chúng thực hiện hàng nghìn thao tác nhỏ ngẫu nhiên mỗi giây. Lệnh dd thường dùng chỉ đo tốc độ ghi tuần tự, nên kết quả rất ảo.
Đây là kịch bản test Random Write (ghi ngẫu nhiên) để mô phỏng tải Database nặng:
fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reportingThông số quan trọng bạn cần soi kỹ:
- IOPS: Với ổ SSD SATA thông thường, con số này nên đạt trên 5.000. Với NVMe, nó có thể vượt 50.000.
- Latency (Độ trễ): Nếu trung bình trên 20ms, hệ thống của bạn sẽ có cảm giác “lag” rõ rệt dù CPU thấp.
3. Kiểm tra mạng với iperf3
Card mạng ảo virtio rất mạnh, nhưng cấu hình sai MTU có thể khiến tốc độ giảm một nửa. Để test, bạn cần chạy iperf3 trên hai máy khác nhau.
Máy đích (Server): iperf3 -s
Máy nguồn (Client): iperf3 -c [IP_SERVER] -t 30 -P 4
Tham số -P 4 sẽ mở 4 luồng song song. Nếu bạn dùng mạng 10Gbps nhưng kết quả chỉ đạt 2-3Gbps, hãy kiểm tra lại thiết lập Multiqueue trên card mạng VirtIO của Proxmox.
Giám sát hệ thống theo thời gian thực
Đừng chỉ đợi kết quả cuối cùng. Trong lúc benchmark, hãy mở một terminal khác chạy htop và iotop để quan sát hành vi hệ thống.
Lệnh sudo iotop -o sẽ cho bạn biết tiến trình fio đang thực sự chiếm bao nhiêu throughput. Nếu cột IO> báo 99% trong khi IOPS vẫn thấp, ổ cứng vật lý của bạn đã chạm ngưỡng giới hạn phần cứng.
Kinh nghiệm thực tế: Tăng 30% hiệu suất
Mình từng gặp trường hợp IOPS rất thấp dù dùng ổ NVMe xịn. Sau khi benchmark, mình phát hiện việc chuyển Disk Bus từ VirtIO Block sang SCSI giúp cải thiện rõ rệt. Kết hợp với controller VirtIO SCSI Single và bật iothread, hiệu suất IOPS tăng thêm 30%.
Đừng đợi đến khi hệ thống thực tế gặp sự cố mới đi tìm nguyên nhân. Hãy benchmark ngay từ đầu để có bộ chỉ số cơ sở (baseline). Điều này giúp bạn dễ dàng so sánh và chẩn đoán lỗi khi nâng cấp hạ tầng sau này.
