Why Your 64GB RAM Server Still Needs Swap
Disabling Swap because you have 64GB of RAM is a classic “optimization” that often backfires. Swap isn’t just an overflow tank for when you run out of memory. It is a core component of the Linux kernel’s memory management. It allows the system to move idle data—like a background daemon that hasn’t been accessed in three days—out of high-speed RAM and onto the disk. This clears room for active processes and the crucial filesystem cache.
Without this safety net, you’re playing Russian Roulette with the Out of Memory (OOM) Killer. When RAM hits 99% capacity, the kernel starts terminating processes to prevent a total system lockup. Usually, it targets your heaviest hitters: MySQL, Java, or Nginx. I’d rather see a temporary 100ms latency spike than a 503 error because my database crashed. Modern strategies like Swapfiles and zSwap let you keep that safety net without sacrificing speed.
Setting Up a Flexible Swapfile
Forget dedicated disk partitions. Resizing a partition on a live production server is risky business. Swapfiles are now the industry standard because they offer the same performance as partitions but can be resized or deleted as easily as a text file.
Creating the Swapfile
Start by allocating space. If your server has less than 4GB of RAM, match the Swap size to the RAM. For larger systems, a fixed 2GB to 4GB buffer is usually enough. Here is how I set up a 4GB Swapfile on a standard Ubuntu node:
# Use fallocate for instant allocation
sudo fallocate -l 4G /swapfile
# On older XFS filesystems, use dd if fallocate fails:
# sudo dd if=/dev/zero of=/swapfile bs=1M count=4096Don’t skip the permissions. Only the root user should be able to read this file, as it often contains sensitive data pulled straight from memory.
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfileMaking Swap Persistent
Manual activation won’t survive a reboot. To make the change permanent, you must update the filesystem table (/etc/fstab). Always back up this file first—a typo here can prevent your server from booting.
# Create a safety backup
sudo cp /etc/fstab /etc/fstab.bak
# Append the entry
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabFine-Tuning: Swappiness and Cache Pressure
Standard Linux distros ship with desktop-centric defaults. The kernel parameter vm.swappiness controls how aggressively the system moves data to disk. The default is usually 60, which is far too aggressive for most servers.
Adjusting vm.swappiness
Values range from 0 to 100. For database-heavy workloads, set this to 10 or even 1. This tells the kernel: “Only use the disk if you absolutely must.” This prevents the system from “thrashing”—a state where it spends more time moving data back and forth than actually running your application.
# View current setting
cat /proc/sys/vm/swappiness
# Apply a temporary fix to test
sudo sysctl vm.swappiness=10VFS Cache Pressure
Filesystem speed often depends on vm.vfs_cache_pressure. This dictates how long the kernel keeps directory and inode data in memory. On my production nodes, I lower this from 100 to 50. This keeps file metadata cached longer, which speeds up directory traversals and file lookups.
Make these changes permanent by adding them to /etc/sysctl.conf:
vm.swappiness=10
vm.vfs_cache_pressure=50Next-Level Speed with zSwap
zSwap is a hidden gem for performance. It acts as a compressed write-back cache for your swap. Instead of pushing a memory page directly to the slow SSD, zSwap compresses it—often at a 3:1 ratio—and keeps it in a small pool within your RAM.
Disk I/O is the ultimate bottleneck. By using a few CPU cycles for zstd compression, you avoid the massive latency of writing to disk. I’ve seen this cut disk wait times by 15% during heavy traffic spikes on 4GB VPS instances. The oldest pages only get pushed to the actual Swapfile when the compressed pool is full.
Verify your kernel support:
grep -i zswap /boot/config-$(uname -r)To enable it at boot, edit your GRUB configuration. I recommend using the zstd compressor and capping the pool at 25% of your total RAM.
# Edit /etc/default/grub
# Update GRUB_CMDLINE_LINUX_DEFAULT to include:
# zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=25
sudo update-grubVerification & Real-Time Monitoring
Settings are useless if you don’t verify them. Use swapon --show for a quick status check. It reveals exactly which files are active and their current utilization.
swapon --show
# NAME TYPE SIZE USED PRIO
# /swapfile file 4G 1.2G -2If you suspect the system is thrashing, run vmstat 2. Watch the si (swap-in) and so (swap-out) columns. If these numbers stay consistently high for more than a few seconds, you either need a RAM upgrade or your swappiness is still too high for your workload.
To see how much memory you’re actually saving with compression, check the kernel’s debug stats:
sudo grep -r . /sys/kernel/debug/zswap/Optimizing Swap is a balancing act. By combining a properly sized Swapfile with tuned kernel parameters and zSwap compression, you can keep your servers stable under extreme pressure. It is a high-reward optimization that ensures your services stay online when every megabyte counts.
