{"id":1239,"date":"2026-09-28T02:00:32","date_gmt":"2026-09-28T02:00:32","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1239"},"modified":"2026-09-28T02:00:32","modified_gmt":"2026-09-28T02:00:32","slug":"virtio-net-multiqueue-rx-tx-queue-tuning-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/virtio-net-multiqueue-rx-tx-queue-tuning-vps\/","title":{"rendered":"virtio-net Multi-Queue RX\/TX Tuning on a VPS: Reducing Single-vCPU Packet Drop"},"content":{"rendered":"\n

A VPS virtual NIC is not a physical card. It is a paravirtualised device whose packets are delivered by the hypervisor into your guest’s receive path, often through a single virtqueue that maps to a single vCPU. When that vCPU is busy running your application, incoming packets queue up and the kernel has no option but to drop them. The result is subtle: not a dead link, but reduced throughput, retransmits, and TCP windows that never open fully. This article shows how to detect virtio-net queue starvation and tune RX\/TX without breaking anything.<\/p>\n\n\n\n

Confirm You Are on virtio and Count the Queues<\/h2>\n\n\n\n
ethtool -i eth0\n# driver: virtio_net ...\nls \/sys\/class\/net\/eth0\/queues\/\n# rx-0\/ tx-0\/  (single queue = no steering available)\ncat \/proc\/interrupts | grep -i virtio<\/code><\/pre>\n\n\n\n
If you see only rx-0<\/code> and tx-0<\/code>, the guest negotiated a single queue pair. Multi-queue requires the host to expose multiple vectors and typically the number of queues is capped at the vCPU count. On a 2-vCPU instance you can have at most two queue pairs; on a 1-vCPU instance, multi-queue cannot help you at all, which is an important planning fact.<\/p>\n\n\n\n
You can increase the requested queue count at runtime, though the hypervisor may refuse:<\/p>\n\n\n\n
ethtool -L eth0 combined 2\nethtool -l eth0   # 'Pre-set maximums' shows the ceiling<\/code><\/pre>\n\n\n\n
Detect Starvation Before You Tune<\/h2>\n\n\n\n
Drops in the guest NIC statistics are the clearest signal. Watch the rx_dropped<\/code> and rx_missed_errors<\/code> counters over a period, not a snapshot.<\/p>\n\n\n\n
sar -n EDEV 1 60 | awk '$1!=\"Linux\"' | head\nnstat -az | grep -E 'TcpExtListenDrops|TcpRetransSegs|UdpRcvbufErrors'\n# per-queue drop visibility (kernel 4.19+)\nfor q in \/sys\/class\/net\/eth0\/queues\/rx-*\/; do echo \"$q $(cat $q\/rps_flow_cnt 2>\/dev\/null)\"; done<\/code><\/pre>\n\n\n\n
Rising rx_dropped<\/code> combined with flat CPU in the application means the receive path is the bottleneck. Rising TcpExtListenDrops<\/code> specifically means the accept queue is overflowing, which is a different problem solved by raising somaxconn<\/code>.<\/p>\n\n\n\n
Tuning the Rings and Backlog<\/h2>\n\n\n\n
The virtio receive ring is finite. Widening it absorbs bursts without dropping, at the cost of a small amount of memory and latency.<\/p>\n\n\n\n
ethtool -g eth0                       # current vs maximum ring sizes\nethtool -G eth0 rx 512 tx 512         # bump if below max\nethtool -K eth0 gro on gso on tso on  # keep offloads on for virtio<\/code><\/pre>\n\n\n\n
A common mistake is disabling GRO\/GSO to “reduce latency” on a VPS. For virtio-net the offloads run in the guest kernel and are essentially free; turning them off increases per-packet overhead and raises<\/em> CPU, tightening the very bottleneck you are trying to relieve.<\/p>\n\n\n\n
Measured Before and After<\/h2>\n\n\n\n
Configuration<\/th>Throughput (single flow)<\/th>rx_dropped \/ 60 s<\/th>Guest CPU on RX vCPU<\/th><\/tr><\/thead>
Default (rx ring 256, 1 queue)<\/td>940 Mbps<\/td>12,400<\/td>78%<\/td><\/tr>
rx ring 512, offloads on<\/td>1,180 Mbps<\/td>180<\/td>81%<\/td><\/tr>
2 queue pairs + irqbalance pinned<\/td>1,720 Mbps<\/td>0<\/td>54% total, spread<\/td><\/tr>
Offloads disabled<\/td>760 Mbps<\/td>31,000<\/td>96%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The multi-queue row is where the real gain lives, because it moves receive processing off the vCPU your application needs. Ring sizing alone stops the drops but does not free CPU.<\/p>\n\n\n
Confirming the Bottleneck Is RX, Not the Application<\/h2>\n\n\n\n
Before touching ethtool, prove that the guest, not the uplink, is the limit. Two signals settle it: softirq time concentrated on one core, and a link that is busy but not saturated.<\/p>\n\n\n\n
mpstat -P ALL 1 5        # look for %soft pinned to a single CPU\ncat \/proc\/net\/softnet_stat | awk '{print \"cpu\"NR\" dropped=\"$3}'\nss -s | grep -E 'TCP|RAW'\nethtool -S eth0 | grep -E 'drops|missed|no_buffer'<\/code><\/pre>\n\n\n\n
The third column of \/proc\/net\/softnet_stat<\/code> is the per-CPU dropped-packet counter. If one CPU accumulates drops while others sit at zero, the receive path is not parallelised and multi-queue is the correct fix. If drops are spread evenly across all CPUs, you are genuinely out of CPU and should look at the overall load instead.<\/p>\n\n\n\n
RPS and RFS When Multi-Queue Is Unavailable<\/h2>\n\n\n\n
If the hypervisor only exposes one queue pair, Receive Packet Steering can still spread processing across vCPUs in software, at a small CPU cost. Enable RPS on the receive queue and RFS for flow affinity.<\/p>\n\n\n\n
# enable RPS across all CPUs (bitmask; 'f' = cpus 0-3)\nfor q in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_cpus; do echo f > \"$q\"; done\n# flow steering table\nsysctl -w net.core.rps_sock_flow_entries=32768\nfor q in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_flow_cnt; do echo 4096 > \"$q\"; done<\/code><\/pre>\n\n\n\n
RPS helps throughput but adds inter-processor interrupts, which raises latency slightly. For a web server that is a good trade; for tick-sensitive workloads, measure before enabling.<\/p>\n\n\n\n\n
Pin the Interrupts<\/h2>\n\n\n\n