TL;DR / Summary: A 1 GB VPS does not run out of memory suddenly; it gets killed by the kernel when cache and processes crowd the last hundred megabytes. A swap file sized at 1–2 GB, low swappiness, and a weekly look at swap-in and swap-out rates will keep a small box stable without shredding the disk.
Why a 1 GB box dies at 900 MB
Linux uses free memory for page cache, so a healthy small server usually shows very little “free” RAM and that is not a problem. The problem starts when an application allocates faster than the kernel can reclaim cache, the OOM killer picks the largest process, and your database or web worker disappears without a stack trace.
Swap does not add performance. It adds a pressure valve, so the kernel can move cold anonymous pages to disk instead of killing something. On a budget VPS that valve is often the difference between a slow minute and a dead service.
Swap file size: what actually fits
The old advice of twice the RAM was written for machines that hibernated. A server does not hibernate, so the useful question is how much cold memory you need to park. For a 1 GB box running a web app and a small database, 1 GB of swap is usually enough; 2 GB is generous and still cheap.
Check disk first. Many budget plans ship with 20–25 GB of SSD, and a 2 GB swap file plus logs plus images can push you toward a full filesystem, which is a worse failure than memory pressure. Reserve at least 3 GB of free disk after creating the file.
Sizing shortcuts by workload
- Static site or reverse proxy — 512 MB swap is plenty
- Small database plus app — 1 GB, watch the cache hit rate
- Build jobs or image processing — 2 GB, and expect it to be used
Creating and mounting the file correctly
Allocate with fallocate -l 1G /swapfile on ext4 or xfs, set permissions to 600, run mkswap, then swapon. On btrfs, fallocate creates an unreclaimable extent, so use dd or a dedicated swap subvolume instead. Getting this wrong produces a file that works until the disk fills.
Add the entry to /etc/fstab so the swap returns after a reboot, and confirm with swapon --show plus free -h. A swap file that only exists until the next provider maintenance window is worse than none, because you will have stopped watching for memory issues.
Swappiness and cache pressure
vm.swappiness controls how eagerly the kernel moves anonymous pages to swap. A value of 60 is the default and is too eager for a server that wants hot application memory to stay resident. Set 10 for a small box, or 20 if you would rather avoid OOM kills at the cost of a little latency.
vm.vfs_cache_pressure controls how aggressively inode and dentry caches are reclaimed. Dropping it to 50 keeps directory lookups fast on a busy file tree. Persist both in /etc/sysctl.d/99-tuning.conf, then apply with sysctl --system so the settings survive upgrades.
Watching for thrash instead of guessing
Look at vmstat 5 and read the si and so columns. Occasional small values are normal. Sustained swap-in above a few hundred kilobytes per second means the working set does not fit, and adding more swap will only make the machine slower. That is the signal to remove a process or buy more RAM.
Also read SwapCached in /proc/meminfo. If it grows steadily and never shrinks, pages are being written out and read back repeatedly. A single spike during a nightly backup is fine; a rising line all afternoon is not.
When swap hides a memory leak
Swap is a diagnostic tool as much as a safety net. If a service’s resident memory climbs every day and swap slowly fills behind it, you have a leak, and a bigger swap file buys you a longer interval between crashes rather than a fix.
Compare RSS for the process over a week with ps -o rss= -p PID. Flat RSS with rising swap means normal cold pages. Both rising together means restart the service on a schedule while you find the cause, and set a memory limit so it fails predictably rather than dragging the whole box down.
Adding swap to a leaking service is like adding a bigger bucket under a leaking roof. It changes when you notice, not what happens.
SSD wear and an honest threshold
Modern SSDs tolerate far more writes than a small VPS will generate, and a swap file on a provider’s redundant storage is not a serious wear concern at this scale. What does hurt is constant thrashing, which multiplies writes and slows everything else on the host.
Set a simple alarm: alert when used swap exceeds 60 percent for more than fifteen minutes, and when si/so stay nonzero for ten consecutive samples. Two alerts, checked by any monitoring tool, catch both the leak and the undersized box.
Reading your own numbers after a week
Give the change seven days, then look at three numbers: peak swap used, peak swap-out rate, and free disk. If swap never moved, keep it anyway as insurance and stop tuning. If it filled once during a deploy and recovered, you are sized correctly.
If it sits above half permanently, the honest conclusion is that the workload needs more RAM than a budget plan provides. Affordable VPS servers with 2 GB double the headroom for a few dollars more, and that is usually a better purchase than a third gigabyte of swap on a disk that was never meant to be memory.
Related Articles：
Prepaid vs Postpaid VPS Billing: The Real Savings Math After Fees and Refunds
Budget vs Premium VPS: Real Cost-Benefit Analysis with Outage and Downtime Math
Fix VPS Bottlenecks Before You Upgrade: A Cost-First Tuning Sequence
VPS Migration Downtime Windows: Trading Cutover Speed Against Preparedness Cost
