⭐ Featured

VPS Performance Tuning 2026: A Practical Guide to Getting More From Your Server

From the AES-NI re-enabling trick to kernel tuning, NVMe optimization, and TCP BBR. Real benchmarks included.

July 13, 2026 | 10 min read | 239 views

Why Your VPS Is Slower Than It Should Be

You bought a VPS with 4 cores and 8GB of RAM. The spec sheet looked great. Then you ran a benchmark and the numbers came back... underwhelming. Sound familiar?

This happened to a lot of people. You spin up a server, expect it to fly, and instead it crawls. The good news is that most VPS instances ship with latent performance you can unlock. The bad news is nobody tells you about it.

In July 2026, a LowEndTalk community member named @forest published a technique for re-enabling AES-NI hardware acceleration on VPS instances where the provider disabled it. The performance difference was staggering: AES-128-GCM throughput jumped from roughly 250MB/s to over 440MB/s at the 8192-byte block size. That is not a marginal gain. It is a 75% improvement in encryption throughput, achieved with a single environment variable.

The technique works because QEMU only changes the CPUID instruction to stop advertising AES-NI support. The actual AES-NI instructions cannot be trapped, so they always work if the guest attempts to issue them and the hardware supports them.

That one discovery got me thinking about all the other hidden performance wins sitting inside a typical VPS. So I put together this guide. It covers CPU feature passthrough, storage I/O tuning, kernel parameters, network stack optimization, and benchmarking tools. Everything here has been tested on real hardware.

Step 1: Audit Your CPU Features

Before tuning anything, figure out what your VPS actually has. Providers present a virtualized CPU, and the flags you see in /proc/cpuinfo might not reflect the physical hardware underneath.

Reading CPU Flags

Run this command to see what instruction sets your VPS exposes:

cat /proc/cpuinfo | grep flags | head -1

The flags that matter most for performance:

aes — AES-NI hardware encryption acceleration. Missing this means every TLS handshake and disk encryption operation runs in software, which is dramatically slower.
avx / avx2 / avx512 — Advanced Vector Extensions. These accelerate numerical computations, video encoding, and machine learning inference workloads.
vmx / svm — Hardware virtualization passthrough. You need this if you want to run nested VMs or containers with hardware acceleration.
fma — Fused Multiply-Add. Important for scientific computing and some crypto operations.
nopie — Some budget providers disable PIE (Position Independent Executables) for a small performance gain at the cost of security. Worth knowing which side your provider chose.

What to Do If AES-NI Is Missing

Do not force an application to use AES-NI or alter CPUID feature masks from inside a guest. A missing aes flag can mean the instruction is not exposed or is unavailable; forcing it can cause an illegal-instruction crash or misleading benchmark result. First ask the provider which CPU model and flags are exposed, then test the application normally. If hardware crypto is a hard requirement, select a plan that documents the feature and verify it after provisioning with lscpu and an application benchmark.

Step 2: Optimize Storage I/O

Storage is where most VPS instances leave performance on the table. The gap between a well-configured NVMe setup and a default install can be 3x to 5x in random read workloads.

NVMe vs SSD vs HDD

If your provider offers NVMe, take it. The difference is not subtle. A typical SATA SSD delivers around 500MB/s sequential reads with 50,000 to 100,000 IOPS. An NVMe drive pushes 3,000MB/s and 500,000+ IOPS. For database workloads, the IOPS difference matters more than sequential throughput.

Some providers advertise "SSD" but actually run SATA SSDs in a RAID array with significant overhead. Check actual performance with:

fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --size=1G --runtime=30 --time_based

Results below 10,000 IOPS on a supposedly NVMe-backed VPS suggest either overselling or a misconfigured I/O scheduler.

I/O Scheduler Tuning

Linux ships with several I/O schedulers. The right choice depends on your storage type:

none / noop — Best for NVMe and SSD. The device has its own internal scheduler, so the kernel scheduler just adds latency.
mq-deadline — Good for SATA SSDs and mixed workloads. Prevents I/O starvation.
bfq — Designed for slow mechanical drives and interactive desktop use. Not ideal for server workloads.

Check your current scheduler:

cat /sys/block/sda/queue/scheduler

Switch to noop for NVMe drives:

echo none > /sys/block/sda/queue/scheduler

This change takes effect immediately and persists until reboot. Add it to a systemd unit or rc.local for persistence.

Filesystem Choice

Most VPS images come with ext4 by default. ext4 is reliable and well-understood. But if your workload involves many small files (like a web server serving static assets, or a CI pipeline), XFS often performs better in concurrent write scenarios.

For databases, the filesystem choice interacts with the database's own write strategy. PostgreSQL on ext4 with data=writeback and barrier=0 can see 20-30% write improvement, but this trades durability for speed. Only do this if you have replication or can tolerate data loss on power failure.

Step 3: Kernel and Memory Tuning

The default sysctl values on most Linux distributions are conservative. They prioritize stability over raw throughput, which makes sense for a generic install but leaves performance on the table for a dedicated workload.

Swap Behavior

By default, Linux starts swapping when memory usage hits 60%. On a VPS where memory is a fixed allocation, aggressive swapping can cause cascading slowdowns. Check your swappiness:

cat /proc/sys/vm/swappiness

The default is 60. For a VPS running databases or web applications, set it to 10:

sysctl vm.swappiness=10

If your VPS has no swap at all (some providers disable it), this setting is irrelevant, but you should make sure your applications handle out-of-memory conditions gracefully instead of relying on swap as a safety net.

VFS Cache Pressure

The vfs_cache_pressure parameter controls how aggressively the kernel reclaims memory used for directory and inode objects. The default of 100 is reasonable for most workloads. Lower it to 50 if your server serves many small files, so directory entries stay cached longer:

sysctl vm.vfs_cache_pressure=50

Transparent Huge Pages

Transparent Huge Pages (THP) can help or hurt depending on your workload. For databases like Redis and PostgreSQL, THP often causes latency spikes because the kernel spends time coalescing pages. Disable it for database workloads:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

For general-purpose web servers and application servers, leaving THP on (the default) is fine and may improve performance for memory-intensive applications.

Step 4: Network Stack Optimization

Network performance tuning is where you can pick up significant latency reductions, especially if your VPS serves users across long distances.

Enable TCP BBR

TCP BBR is a congestion control algorithm developed by Google. It outperforms the default CUBIC algorithm on long-distance connections with packet loss. On a VPS in Frankfurt serving users in Singapore, switching to BBR can reduce latency by 20-40% under load.

Enable it:

sysctl net.core.default_qdisc=fq
sysctl net.ipv4.tcp_congestion_control=bbr

Verify it took effect:

sysctl net.ipv4.tcp_congestion_control

You should see bbr in the output. If you see an error, your kernel might be too old. BBR requires kernel 4.9 or later. Most VPS images from 2024 onward have this.

TCP Buffer Sizes

Default TCP buffer sizes are tuned for low-bandwidth connections. On a VPS with a gigabit or 10-gigabit uplink, larger buffers allow the TCP window to grow enough to fill the pipe on high-latency links.

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

These values allow up to 16MB per connection in each direction. For most VPS workloads this is sufficient. If you run a high-throughput file server or CDN origin, you can go higher, but watch your total memory usage.

Connection Tracking

If your VPS handles many concurrent connections (like a proxy or load balancer), the default conntrack table size of 65536 can be a bottleneck. Increase it:

sysctl net.netfilter.nf_conntrack_max=262144

This uses more kernel memory (roughly 300 bytes per entry) but prevents connection tracking table exhaustion under high load.

Step 5: Benchmarking Your Results

Tuning without measurement is guesswork. Here are the tools that actually work for VPS performance verification.

CPU Benchmarking

For raw CPU performance, use sysbench:

sysbench cpu --cpu-max-prime=20000 --threads=4 run

This gives you events per second, which you can compare across providers or before and after tuning. Typical results range from 500 events/sec on a budget VPS to 3000+ on a high-frequency core.

Storage Benchmarking

For disk I/O, use fio with a realistic mixed workload:

fio --name=mixed --ioengine=libaio --iodepth=32 --rw=randrw --rwmixread=70 --bs=4k --size=2G --runtime=60 --time_based

This simulates a 70% read / 30% write workload, which is close to what most web applications produce. Compare the IOPS and latency numbers before and after your scheduler and filesystem changes.

Network Benchmarking

For network throughput between your VPS and a target location, use iperf3. Run the server on your VPS:

iperf3 -s

Then run the client from another machine:

iperf3 -c your.vps.ip -P 4 -t 30

The -P 4 flag opens 4 parallel streams, which gives a better picture of aggregate throughput than a single stream.

Putting It All Together

Here is a quick checklist to run through on any new VPS:

Check CPU flags and re-enable AES-NI if hidden
Verify storage type and set the right I/O scheduler
Set swappiness to 10 and adjust vfs_cache_pressure
Disable THP for database workloads
Enable TCP BBR and increase buffer sizes
Run before and after benchmarks with sysbench, fio, and iperf3

The AES-NI trick alone can deliver a 75% improvement in encryption throughput. Combined with storage tuning, kernel parameter adjustments, and network optimization, you can often squeeze 2x to 3x more real-world performance out of the same VPS without upgrading to a more expensive plan.

Provider-Specific Considerations

Not all tuning advice applies equally to every provider. The virtualization technology your VPS uses determines what you can and cannot change.

KVM-Based VPS

KVM is the most common virtualization for modern VPS offerings. It provides near-native performance and allows full kernel customization. All the tuning steps in this guide apply to KVM VPS instances. Providers like Hetzner, Vultr, DigitalOcean, and Linode use KVM.

OpenVZ / LXC Containers

OpenVZ and LXC are container-based virtualization. You share a kernel with other tenants, so kernel parameter changes (sysctl, TCP BBR, swappiness) are controlled by the host node and cannot be changed from inside your container. CPU flags reflect the host, not a virtualized CPU, so the AES-NI trick is usually unnecessary. Storage I/O is also managed by the host.

If you are on OpenVZ and performance is poor, the bottleneck is likely the host node being oversold. No amount of tuning inside your container will fix that. The solution is to switch to a KVM provider.

Dedicated Servers

If you have a dedicated server, you have full hardware access. Every tuning option is available, and you do not need to worry about CPUID masking or feature passthrough. The AES-NI trick is irrelevant because you have direct access to the physical CPU.

Realistic Expectations

Performance tuning is not magic. A 2-core VPS with 4GB of RAM will not suddenly handle a million requests per second because you changed the I/O scheduler. What tuning does is remove artificial bottlenecks that your provider or distribution maintainer put in place for safety or compatibility.

The biggest wins come from matching your configuration to your actual workload. A database server needs different tuning than a static file server. A proxy server needs different network settings than a compute node. Take the time to understand what your VPS is doing before you start changing parameters.

And always benchmark before and after. The only thing worse than not tuning is tuning blindly and not knowing whether it helped.