How to Set Up zram on a Small VPS

zram provides a compressed block device in RAM that Linux can use as swap. It can help a small VPS handle some temporary memory pressure, but it does not add physical RAM or guarantee that an application will avoid an out-of-memory failure. Compression results and CPU overhead depend on the workload.

This guide uses Ubuntu 24.04 and systemd-zram-generator. Use a sudo-capable account and arrange console access before changing a remote server’s memory configuration. A container-based VPS may not allow loading kernel modules; ask the provider rather than forcing an unsupported kernel change.

Inspect the current configuration

free -h
swapon --show
zramctl
uname -r

Keep existing disk swap and record its priority. If zram is already managed by another tool, do not configure the same device with two services. Inspect existing files under /etc/systemd/zram-generator.conf and /etc/systemd/zram-generator.conf.d/ before editing; preserve any unrelated settings.

Install the generator and check kernel support

sudo apt-get update
sudo apt-get install systemd-zram-generator
modinfo zram

A module information response indicates support is available. A module-not-found error can mean a missing matching module package or a provider kernel without zram. Ubuntu’s generic kernel packages may provide the module through a matching extra-modules package, but availability depends on the running kernel. Check that exact package first:

apt-cache policy "linux-modules-extra-$(uname -r)"

If it has an appropriate candidate for your Ubuntu kernel, an administrator can install that matching package. Do not install modules for every file in /boot or replace the provider’s kernel without a recovery plan. Package download and installed sizes vary.

Configure a conservative starting size

For a new configuration, create /etc/systemd/zram-generator.conf with:

[zram0]
zram-size = ram / 2
compression-algorithm = zstd
swap-priority = 100

zram-size is logical uncompressed capacity, not memory reserved in advance. Actual consumption grows with stored pages, compression results and metadata. Half of physical RAM is a starting point, not a universal optimum. Already-compressed or encrypted data may compress poorly.

The selected compression algorithm must be available in the server’s kernel. If setup reports that zstd is unavailable, consult the installed kernel’s supported algorithms rather than repeatedly restarting a failing unit. Compare zram’s priority with all existing swap devices; 100 is preferred only over devices with a lower priority.

On a server without an active zram device, load the generated unit and start it:

sudo systemctl daemon-reload
sudo systemctl start dev-zram0.swap
swapon --show
zramctl

Confirm that /dev/zram0 appears with the intended size and priority. A successful package installation alone does not establish that the device is active. Check failures with:

sudo systemctl status systemd-zram-setup@zram0.service --no-pager
sudo journalctl -u systemd-zram-setup@zram0.service -n 50 --no-pager

Measure the actual memory trade-off

In zramctl, DATA describes uncompressed stored data, COMPR its compressed representation and TOTAL the memory used including overhead. Compare those values during your normal workload, alongside available RAM, CPU utilization and application latency. A high compression ratio does not by itself establish acceptable performance.

Keep lower-priority disk swap if appropriate for the service. It can provide additional capacity, but it has its own latency and storage costs. Do not format, truncate or recreate an existing swap file. Creating a new file requires filesystem-specific checks and sufficient disk space; this guide deliberately does not overwrite /swapfile.

Kernel updates and configuration changes

After a kernel update, verify that the next kernel has zram support and that the generator package remains installed. Whether extra modules follow upgrades depends on the installed kernel metapackages. After a planned reboot, rerun swapon --show and inspect the service journal if the device is absent.

Editing the configuration does not resize a device that is already active. Before changing or disabling it, stop nonessential workloads, assess available RAM and other swap capacity, and schedule a maintenance window. swapoff must move pages elsewhere and can fail or cause severe memory pressure. Do not run it blindly on a nearly full VPS.

For removal, inspect the generator’s installed manual and all vendor/local configuration files. Deleting one local file can expose a vendor default rather than disable zram. Remove or override only the settings you own, then verify the effective result during the planned restart. Preserve other swap devices and unrelated configuration.

Troubleshooting

• Module unavailable: check the exact running kernel and virtualization restrictions. A package for another kernel will not fix the active kernel.
• Device missing: inspect the setup unit and journal for configuration, algorithm or module errors. Do not assume daemon-reload alone repairs every failure.
• Memory pressure continues: check total RAM, swap usage and the application. Reduce concurrency or add RAM when demand exceeds capacity; increasing logical zram size is not guaranteed to solve it.
• Slow application: compare CPU and memory pressure before and after. Compression trades CPU time for potentially lower memory use.

For the configuration syntax and defaults, see the upstream zram-generator manual. Use your distribution’s installed manual for version-specific behavior.