The sub-$5 VPS tier is full of noise. Most providers oversell, throttle disk I/O after the first week, or assign you a neighbor running crypto miners. You already know the usual suspects by name. What you need is the operational knowledge to extract real performance from constrained hardware—and to recognize when a plan is genuinely usable versus marketing fluff.
I've run production workloads on budget VPS boxes for years. The difference between a plan that collapses under light load and one that hums along at 80% CPU for months often comes down to a few sysctl knobs, the right I/O scheduler, and knowing which processes to starve when RAM runs low.
Why most cheap VPS plans fail under real load
Overselling is the obvious problem. A hypervisor with 64 GB of physical RAM might host 80 VMs each "allocated" 1 GB. That works fine until 20 of them actually use their memory at once.
Disk I/O is the silent killer. Shared SSD storage on a hypervisor means your IOPS budget depends on what everyone else is doing. I've seen MySQL grind to a halt on a VPS that benchmarked beautifully during signup because the neighbor started a daily backup job at 3 AM.
Network throttling appears after the trial period. Burst speeds look great in tests; sustained throughput over 24 hours tells the real story. Providers rate-limit by total transfer or by sustained Mbps, and they don't advertise which.
Kernel tuning for memory-constrained environments
With 1 GB or less, the default kernel parameters will swap aggressively and trash your I/O. Start by adjusting vm.swappiness.
sudo sysctl vm.swappiness=10
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
A value of 10 tells the kernel to prefer keeping active pages in RAM and only swap when necessary. The default of 60 is tuned for desktop workloads with plenty of memory.
Next, tune vm.vfs_cache_pressure. The default of 100 means the kernel reclaims dentry and inode cache at the same rate as page cache. Lower it to prefer keeping filesystem metadata in memory.
sudo sysctl vm.vfs_cache_pressure=50
echo "vm.vfs_cache_pressure=50" | sudo tee -a /etc/sysctl.conf
For workloads that do a lot of small writes—logs, databases, mail queues—dirty page writeback settings matter. If vm.dirty_ratio is too high, a sudden flush will freeze the system for seconds.
sudo sysctl vm.dirty_ratio=10
sudo sysctl vm.dirty_background_ratio=5
echo "vm.dirty_ratio=10" | sudo tee -a /etc/sysctl.conf
echo "vm.dirty_background_ratio=5" | sudo tee -a /etc/sysctl.conf
These values force the kernel to start background writeback earlier and cap the total dirty pages lower. You trade a bit of write coalescing for predictable latency.
I/O scheduler changes that actually help
Most cheap VPS instances run on virtio-blk or virtio-scsi devices. The default scheduler is often mq-deadline or none. Check yours:
cat /sys/block/vda/queue/scheduler
If you see none, the hypervisor is handling all scheduling and you can't change it. If you see mq-deadline, consider switching to bfq for better interactive performance under load.
echo bfq | sudo tee /sys/block/vda/queue/scheduler
To make it permanent, add a udev rule:
echo 'ACTION=="add|change", KERNEL=="vda", ATTR{queue/scheduler}="bfq"' | sudo tee /etc/udev/rules.d/60-scheduler.rules
BFQ prioritizes latency-sensitive I/O and prevents one process from starving others. I've seen WordPress admin pages go from 8-second loads to sub-2-second after this change alone on a shared-disk VPS.
Swap configuration for the 1 GB tier
Don't skip swap. The advice to "just add more RAM" doesn't apply when your budget is $5. Instead, configure swap intelligently.
Create a swap file instead of a partition so you can resize it later:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab
Two gigabytes is a good starting point for a 1 GB VPS. The kernel will use it as overflow, not as primary working memory with vm.swappiness=10.
If your provider throttles disk I/O, swap becomes dangerous. A swapping process can cause 30-second hangs while the kernel waits for pages to come back. Monitor swap usage:
watch -n 5 free -h
If you consistently see more than 50% of swap in use, your workload is too big for the VPS. No amount of tuning will fix that.
Memory limits with systemd and cgroups
Systemd lets you cap memory per service, which prevents one runaway process from triggering the OOM killer and taking down your database.
For example, limit PHP-FPM to 400 MB:
sudo systemctl edit php8.1-fpm.service
Add these lines:
[Service]
MemoryMax=400M
MemoryHigh=350M
MemoryHigh is a soft limit; the kernel will throttle the process. MemoryMax is a hard limit; exceeding it kills the process. This gives you predictable resource allocation even when traffic spikes.
Apply the same pattern to MySQL, Redis, or any other service. Check current usage first:
systemctl status mysql.service
Look for the "Memory" line in the output. That tells you the actual working set.
TCP tuning for high-latency or lossy links
Cheap VPS providers often peer badly or route your traffic through congested links. If you see high packet loss or jitter, TCP tuning can help.
Increase the TCP receive buffer:
sudo sysctl net.ipv4.tcp_rmem="4096 87380 16777216"
echo "net.ipv4.tcp_rmem=4096 87380 16777216" | sudo tee -a /etc/sysctl.conf
And the send buffer:
sudo sysctl net.ipv4.tcp_wmem="4096 65536 16777216"
echo "net.ipv4.tcp_wmem=4096 65536 16777216" | sudo tee -a /etc/sysctl.conf
Enable TCP Fast Open to reduce handshake latency:
sudo sysctl net.ipv4.tcp_fastopen=3
echo "net.ipv4.tcp_fastopen=3" | sudo tee -a /etc/sysctl.conf
A value of 3 enables TFO for both client and server roles. This shaves 1 RTT off every new connection.
Finally, enable BBR congestion control if your kernel supports it (4.9+):
sudo sysctl net.ipv4.tcp_congestion_control=bbr
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
BBR handles lossy links much better than the default CUBIC. I've seen download speeds double on a VPS with 2% packet loss after enabling BBR.
Recognizing oversold providers by behavior, not marketing
Real resource guarantees show up in observable metrics. Run stress-ng and watch what happens:
sudo apt install stress-ng
stress-ng --cpu 1 --timeout 60s --metrics-brief
Compare the reported bogo-ops to a known baseline for your CPU model. If the number is 30% lower than expected, the hypervisor is stealing your cycles.
Do the same for disk I/O:
sudo fio --name=seqwrite --rw=write --bs=1M --size=1G --numjobs=1 --runtime=60 --time_based --end_fsync=1
Note the bandwidth and IOPS. Run the test again at different times of day. If evening performance drops by 50% or more, you're on a congested storage backend.
Network tests require an external target. Use iperf3 to a known-good server:
iperf3 -c iperf.he.net -t 60
Run it during peak hours. Consistent throughput within 20% of the advertised speed is acceptable. Drops of 60% or more mean throttling or bad peering.
What to check first when performance degrades
Start with dmesg and look for OOM kills:
sudo dmesg | grep -i oom
If you see recent kills, you've run out of memory. Check which process was the victim and either add swap or tune memory limits.
Next, check I/O wait:
vmstat 1 10
Look at the wa column. Sustained values above 20% mean you're bottlenecked on disk. If this correlates with specific times, a neighbor is hammering the storage.
Finally, check for CPU steal time:
top
Press 1 to see per-CPU stats, then look for %st. Steal time above 5% consistently means the hypervisor is overcommitted. No amount of guest-level tuning will fix that; you need a different provider.
The 8 plans worth testing
I won't name specific brands because pricing and quality shift. Instead, look for these signals:
- KVM or bare-metal hypervisors, not OpenVZ. You need full kernel control.
- Dedicated CPU option, even if it's fractional (0.5 vCPU dedicated beats 1 vCPU shared).
- NVMe storage, not SATA SSD. The IOPS difference is real.
- Transparent SLA with uptime guarantees and published maintenance windows.
- Hourly billing so you can test without commitment.
- IPv6 included as a proxy for modern infrastructure.
- Published looking-glass or network test files so you can measure latency and throughput before signup.
- No forced panels. If cPanel or Plesk is mandatory, you're paying for licenses in the base price.
Test each plan for 72 hours under your actual workload. Synthetic benchmarks lie; real traffic and real database queries reveal the truth.
Monitoring that catches problems before users do
Set up basic Prometheus with node_exporter:
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz
tar xvfz node_exporter-1.6.1.linux-amd64.tar.gz
sudo cp node_exporter-1.6.1.linux-amd64/node_exporter /usr/local/bin/
Create a systemd service:
[Unit]
Description=Node Exporter
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/node_exporter
Restart=on-failure
[Install]
WantedBy=multi-user.target
Save it as /etc/systemd/system/node_exporter.service, then:
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
Point a remote Prometheus instance at your VPS on port 9100. Graph memory usage, disk I/O, and steal time. Set alerts for steal time above 10% or memory usage above 85%.
For a cheaper option, use Netdata's free tier. One-line install:
bash <(curl -Ss https://get.netdata.cloud/kickstart.sh)
It auto-detects everything and gives you per-second graphs. The web UI runs on port 19999.
Why do some VPS plans work fine for weeks then collapse?
Hypervisor neighbors change. A new VM gets placed on your host running a CPU-intensive workload, and suddenly your steal time jumps from 2% to 15%. Disk I/O follows the same pattern—shared resources mean your performance depends on workloads you can't control.
Is 512 MB of RAM ever enough for a web server?
Yes, for static sites or very light PHP apps. Pair it with 1 GB of swap, run nginx instead of Apache, and disable opcache file watcher to save memory. I've served 10k daily visits on 512 MB, but you can't run MySQL locally—use a managed database.
Should I trust providers offering NVMe at sub-$5 pricing?
Depends on the IOPS you actually get. NVMe hardware is cheap now, but if they oversubscribe it heavily, you'll see worse performance than a lightly-loaded SATA SSD. Test with fio before committing.
What's the real difference between guaranteed and burstable CPU?
Guaranteed (dedicated) CPU means you own that slice of the core; your bogo-ops stay consistent. Burstable means you get "up to" X speed but share with others; performance varies wildly based on neighbor activity. For production, pay the extra $1-2/month for guaranteed.
How do I know if my VPS is being throttled?
Run bandwidth and CPU tests at 6-hour intervals for 48 hours. Plot the results. If you see a clear pattern—great performance during off-peak hours, degraded performance evenings and weekends—you're being throttled or the host is oversubscribed.
What to do when tuning hits its limit
No amount of sysctl tweaking will fix a fundamentally oversold host. If steal time stays above 10%, I/O wait consistently exceeds 30%, or you see regular OOM kills despite tuning, move to a different provider.
Benchmark your workload's actual resource needs first. Then find a plan that meets those needs with headroom. A $7/month VPS that performs reliably beats a $4/month one that struggles.
The goal isn't to squeeze the last drop of performance from inadequate hardware. It's to recognize which cheap plans are genuinely usable and tune them to run stably under real load.