A $30-a-Year Los Angeles VPS Benchmarked: Real Bandwidth, Latency and Disk Numbers
TL;DR
This budget Los Angeles VPS measured 74.6 MB/s download (about 626 Mbps), 4.3 ms to the Cloudflare edge, 66.2 ms to GitHub and 356.4 ms to Baidu in mainland China. Disk totals 18.7 GB and dropped from 76% to 40% used after cleanup, leaving 10.2 GB free. With 1964 MB of RAM it runs a reverse proxy, a static site and a Node.js app at roughly 563 MB, while the 3072 MB swap barely moves.
Measured Numbers at a Glance
| Item | Value or note | Caveat |
|---|---|---|
| Location | Los Angeles, US (RackNerd) | Low latency to North America and Cloudflare edge |
| OS | Ubuntu 22.04.5 LTS | Kernel 5.15.0-170-generic |
| CPU | Intel Xeon E5-2690 0 @ 2.90GHz, 1 core | Single core, fine for light services |
| Memory | 1964 MB total, 563 MB used, 1401 MB available | Usage holds steady near 563 MB |
| Swap | 3072 MB total, 4 MB used | Barely touched, memory is not tight |
| Disk | 18.7 GB total, 7.5 GB used (40%), 10.2 GB free | Was 76% used with 4.4 GB free on handover |
| Download bandwidth (measured) | 74.6 MB/s, about 626 Mbps | Single measurement, not a guaranteed peak |
| Latency to Cloudflare edge | 4.3 ms | Good fit as a CDN origin |
| Latency to GitHub | 66.2 ms | Cloning and installing deps feels normal |
| Latency to Baidu (mainland China) | 356.4 ms | Pair with a CDN for mainland users |
| Uptime | 20 days | No reboot at capture time |
| Running systemd services | 16 | Includes caddy and fail2ban-server |
Disk: From 76% Down to 40%
On handover the disk was 19 GB at 76% used with only 4.4 GB free. Four cleanup rounds (logs, apt cache, unused packages) brought it to 40%. Two big offenders: the systemd journal had grown unbounded to about 1.3 GB, and the apt cache and indexes had taken about 1.2 GB.
Current disk layout: /usr 3.9 GB, /root 1.3 GB, /var 236 MB, /boot 95 MB, /etc 38 MB, /tmp 3 MB, /opt 0 MB. Components installed but never used include the Go toolchain (437 MB), snapd, cmake, tesseract, pocketsphinx and pm2 — the main cleanup targets.
# Cap the systemd journal at 200M
sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nSystemMaxUse=200M\n' | sudo tee /etc/systemd/journald.conf.d/size.conf
sudo systemctl restart systemd-journald
journalctl --disk-usage
# Clear apt cache and unused packages (run update before installing again)
sudo apt-get clean
sudo apt-get autoremove --purge -y
sudo apt-get updateMemory and Security: 1.9 GB Is Enough, Port 22 Needs Protection
On 1964 MB of RAM the box runs a reverse proxy, a static site, one Node.js app and several system services, holding around 563 MB while only 4 MB of the 3072 MB swap is used. Top processes: MainThread 50 MB, sshd 32 MB, systemd-journal 30 MB, caddy 28 MB, codex 27 MB, fail2ban-server 23 MB, systemd 18 MB, networkd-dispat 17 MB.
Port 22 is under constant credential-stuffing scans, and the btmp log had grown to 93 MB. After enabling fail2ban, 3 attacking IPs were banned right at startup.
# Install and enable fail2ban to block SSH brute force
sudo apt-get update
sudo apt-get install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
# Check the size of the btmp failed-login log
sudo ls -lh /var/log/btmpFAQ
How much bandwidth does a budget Los Angeles VPS deliver?
It measured 74.6 MB/s, about 626 Mbps — a single measurement, not a guaranteed peak.
Is latency to mainland China high?
Baidu measured 356.4 ms, which is slow for direct mainland users; the 4.3 ms to the Cloudflare edge makes it a good CDN origin.
What can 1.9 GB of RAM handle?
In testing it ran a reverse proxy, a static site, one Node.js app and system services at about 563 MB, with swap barely touched.
Is 18.7 GB of disk enough?
After cleanup it sits at 40% used with 10.2 GB free; the key is capping the journal and clearing the apt cache regularly.
What if SSH is being scanned?
Enabling fail2ban banned 3 attacking IPs at startup; btmp had reached 93 MB and needs clearing too.
Sources
- On-machine measurements (collected 2026-11-06)