Why You Should Never Trust Advertised Specs
Imagine this scenario: it’s 2 AM, and your phone is buzzing non-stop because your web app is as slow as a snail. The Proxmox dashboard still shows CPU/RAM in the green, but users are complaining. The culprit often lies in hidden corners like I/O Wait or virtualization network bottlenecks.
Real-world experience shows that trusting a VPS provider’s default configuration is a major mistake. In my homelab with 12 VMs, I always benchmark everything before installing a database. Virtualization always comes with “Virtualization Overhead.” If you don’t measure it, you won’t know how much hardware power you’re losing to the Hypervisor.
The “Starter” Benchmarking Toolkit
For a comprehensive evaluation, we will use the following three standard tools:
- sysbench: Tests CPU computing power and RAM speed.
- fio: The gold standard for measuring Disk I/O. Don’t use
dd; it only measures the tip of the iceberg. - iperf3: Measures actual bandwidth between VMs or from a VM to the Host.
Quick installation on Ubuntu/Debian:
sudo apt update && sudo apt install fio sysbench iperf3 -yFor CentOS/RHEL, you need to install EPEL first:
sudo yum install epel-release -y && sudo yum install fio sysbench iperf3 -y1. Measuring CPU Power: Avoiding the “Noisy Neighbor” Effect
In a virtualized environment, CPU resources are often shared (overcommitted). If another VM on the same node is running a heavy task, your performance will drop immediately.
The command below will require the CPU to calculate prime numbers to test stability:
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) runPay attention to the events per second section. A real-world example: when I changed the CPU Type from kvm64 to host in Proxmox, this index increased by 15-20%. The host mode allows the VM to take full advantage of the physical CPU’s instruction sets (like AES-NI, AVX).
2. Disk Performance: IOPS is the Deciding Factor
Applications like MySQL or PostgreSQL don’t read and write sequentially. They perform thousands of small random operations every second. The commonly used dd command only measures sequential write speed, leading to misleading results.
Here is a Random Write test scenario to simulate a heavy database load:
fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reportingKey parameters you need to examine closely:
- IOPS: With a standard SATA SSD, this number should be over 5,000. With NVMe, it can exceed 50,000.
- Latency: If the average is over 20ms, your system will feel noticeably “laggy” even if CPU usage is low.
3. Network Testing with iperf3
The virtio virtual network card is very powerful, but incorrect MTU configuration can cut speeds in half. To test, you need to run iperf3 on two different machines.
Target machine (Server): iperf3 -s
Source machine (Client): iperf3 -c [SERVER_IP] -t 30 -P 4
The -P 4 parameter will open 4 parallel streams. If you are using a 10Gbps network but the result is only 2-3Gbps, check the Multiqueue settings on the Proxmox VirtIO network card.
Real-time System Monitoring
Don’t just wait for the final results. While benchmarking, open another terminal and run htop and iotop to observe system behavior.
The sudo iotop -o command will show you how much throughput the fio process is actually consuming. If the IO> column reports 99% while IOPS is still low, your physical disk has reached its hardware limit.
Real-world Experience: Boosting Performance by 30%
I once encountered a case where IOPS was very low despite using a high-end NVMe drive. After benchmarking, I discovered that switching the Disk Bus from VirtIO Block to SCSI provided a significant improvement. Combined with the VirtIO SCSI Single controller and enabling iothread, IOPS performance increased by another 30%.
Don’t wait until a real system failure occurs to look for the cause. Benchmark from the start to establish a baseline. This makes it easier to compare and diagnose errors when upgrading infrastructure later.
