You bought the fastest storage available. NVMe. Low latency. High throughput. Yet your site still feels sluggish, and your database queries take longer than they should. This is a common frustration in support tickets. The hardware is fast, but the software stack is choking it.
NVMe drives change how we think about I/O. They don't just replace SATA; they shift the bottleneck from the disk to the CPU and memory subsystem. If you treat an NVMe VPS like a standard SSD server, you leave performance on the table. In many cases, you actually degrade performance below what a well-tuned SATA drive would offer. This article lists the nine most common mistakes I see in production environments and how to fix them.
1. Ignoring the I/O Scheduler
The default I/O scheduler in many Linux distributions is designed for spinning disks or older SSDs. It assumes high seek times and latency. NVMe drives have near-zero seek time. Using the wrong scheduler adds unnecessary overhead.
Check your current scheduler:
cat /sys/block/nvme0n1/queue/scheduler
If you see mq-deadline or bfq highlighted, you might be fine, but none or noop is often better for raw NVMe performance in high-concurrency web server environments. mq-deadline is a safe default for mixed workloads, but pure read-heavy web servers often benefit from none because the kernel doesn't need to reorder requests that are already fast.
To change it temporarily:
echo none > /sys/block/nvme0n1/queue/scheduler
To make it permanent, add the following to your kernel parameters in /etc/default/grub:
GRUB_CMDLINE_LINUX="... elevator=none"
Then run update-grub or grub2-mkconfig depending on your distro and reboot. This single change can reduce tail latency significantly.
2. Using the Wrong Filesystem Mount Options
Filesystems like XFS and ext4 have mount options that drastically affect performance. The most common mistake is leaving noatime off. Every time a file is read, the filesystem updates the access time. This is a write operation. On a web server reading thousands of static files per second, this creates unnecessary I/O load.
Check your current mount:
mount | grep nvme
Ensure noatime is present. For high-write workloads, nodiratime can also help, though it breaks some backup tools that rely on directory access times.
Edit /etc/fstab to include:
/dev/nvme0n1p1 / ext4 defaults,noatime,nodiratime 0 0
Remount to test:
mount -o remount /dev/nvme0n1p1
This reduces write amplification and frees up I/O bandwidth for actual data operations.
3. Neglecting Swap Space Configuration
NVMe drives are fast, but they are not infinite. If you run out of RAM, the kernel will swap. Swapping to NVMe is better than swapping to SATA, but it is still slow compared to RAM. The mistake here is either having no swap at all or having too much.
No swap means the OOM killer will terminate processes when memory pressure hits. This is bad for stability. Too much swap means the kernel is lazy about freeing memory, keeping dirty pages in RAM longer and delaying write-backs.
For a VPS, a small swap file or partition is sufficient. A 1:1 ratio with RAM is a common starting point, but for web servers, 50% of RAM is often enough. The key is to ensure swap is on the same NVMe device as your root filesystem to avoid cross-device I/O penalties.
Check your swap usage:
swapon --show
free -h
If you see consistent swap usage, your RAM is undersized. No amount of NVMe tuning will fix a RAM shortage. Upgrade the VPS tier first.
4. Disabling Write Caching (or Forcing It Off)
NVMe drives have internal DRAM caches. Some administrators, out of fear of data loss during power cuts, disable write caching at the OS level. This is a mistake for most web hosting scenarios. The risk of data loss is minimal for static content and logs, and the performance gain from write-back caching is substantial.
Check if write caching is enabled:
cat /sys/block/nvme0n1/device/queue/write_cache
If it says write through, you are forcing synchronous writes. For write back, the OS can acknowledge writes before they hit the NAND.
To enable it:
echo 1 > /sys/block/nvme0n1/device/queue/write_cache
Make this persistent via a udev rule or init script. Be aware that this only matters if the drive has a battery-backed cache or if you accept the small risk of data loss on power failure. For most VPS use cases, this risk is acceptable.
5. Not Tuning Transparent Huge Pages (THP)
Transparent Huge Pages are a Linux feature that uses 2MB pages instead of 4KB pages to reduce TLB misses. This sounds good, right? For databases like MySQL or MariaDB, it is often bad. THP can cause latency spikes due to the kernel's compaction process, which pauses memory allocation while it tries to find contiguous memory for a huge page.
Check your current setting:
cat /sys/kernel/mm/transparent_hugepage/enabled
If you see [always], disable it for database servers. Use madvise or never.
To set it to never:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
For web servers without heavy database loads, madvise is a good middle ground. It only uses huge pages for applications that explicitly request them. This is a subtle performance killer that is hard to diagnose without profiling.
6. Using the Wrong CPU Governor
Modern CPUs have power management governors. The default is often powersave, which scales down CPU frequency to save power. On a VPS, you want consistent performance, not power savings. The performance governor keeps the CPU at its maximum frequency, reducing jitter and latency spikes.
Check your current governor:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
If it says powersave or ondemand, switch to performance.
To change it for all CPUs:
for cpu in /sys/devices/system/cpu/cpu[0-7]; do
echo performance > $cpu/cpufreq/scaling_governor
done
Make this persistent by installing cpufrequtils or using a systemd unit. This ensures your CPU doesn't sleep during burst traffic, which is critical for handling sudden spikes in web requests.
7. Ignoring Network Stack Tuning
NVMe speed is useless if your network interface is the bottleneck. Many VPS providers have network interfaces with default buffer sizes that are too small for high-throughput connections. This leads to packet loss and retransmissions, especially during large file downloads or backups.
Check your current buffer sizes:
sysctl net.core.rmem_max
sysctl net.core.wmem_max
Increase these values to match your bandwidth. For a 1Gbps connection, 4MB is a reasonable starting point.
Edit /etc/sysctl.conf:
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 65536 4194304
Apply changes:
sysctl -p
This allows the kernel to buffer more data in memory, reducing the chance of dropping packets when the disk I/O is fast but the network is congested. It’s a simple fix that often goes overlooked.
8. Not Monitoring I/O Latency
You can’t fix what you don’t measure. Many administrators look at CPU and RAM usage but ignore I/O latency. NVMe drives can have latency spikes due to garbage collection or wear leveling. If you don’t monitor this, you won’t know when performance degrades.
Use iostat to check I/O statistics:
iostat -x 1 5
Look at the await and svctm columns. await is the average time (in ms) for I/O requests issued to the device to be serviced. For NVMe, you should see values well under 1ms for reads. If you see values above 5ms consistently, something is wrong.
Use vmstat to check for I/O wait:
vmstat 1
The wa column shows the percentage of time the CPU is waiting for I/O. If this is high, your storage subsystem is the bottleneck. This is where NVMe tuning becomes critical. You need to identify whether the issue is the scheduler, the filesystem, or the hardware itself.
9. Running Outdated Kernel Versions
NVMe support in Linux has improved dramatically in recent years. Older kernels may lack optimizations for newer NVMe controllers, such as multipath support, error recovery, or efficient queue management. Running an outdated kernel can limit your NVMe performance.
Check your kernel version:
uname -r
Ensure you are running a kernel that supports the latest NVMe features. For most modern VPS providers, this means a kernel from the last 2-3 years. Update your kernel if it is older.
sudo apt update && sudo apt upgrade
Or use your distro’s rolling update mechanism. Reboot after updating. This ensures you have the latest drivers and optimizations for your specific NVMe hardware. It’s a simple step that can have a significant impact.
What to Check First
Start with the basics. Check your I/O scheduler, mount options, and CPU governor. These are the most common mistakes and the easiest to fix. Then move on to memory and network tuning. Finally, monitor your I/O latency to ensure your changes are having the desired effect.
NVMe VPS performance is not just about buying fast hardware. It’s about configuring your software stack to take advantage of that speed. Take the time to tune your system. The difference between a sluggish VPS and a fast, responsive one is often just a few configuration changes.
How do I know if my NVMe is working at full speed?
Use fio to benchmark your disk. Compare the results to the manufacturer’s specs. If you are seeing significantly lower throughput, check your I/O scheduler and mount options.
Should I disable swap on an NVMe VPS?
No. Keep a small amount of swap for stability. Disabling swap entirely can lead to OOM kills under memory pressure. A small swap file on the same NVMe device is sufficient.
Does NVMe require a different filesystem?
No. XFS and ext4 both work well with NVMe. XFS is often preferred for large files and high concurrency, while ext4 is more widely supported. Choose based on your workload, not the storage type.