Stop ZFS from eating your entire system RAM during backups

Technical Briefing | 8/20/2026

You probably set up your ZFS pool, enabled deduplication because it sounded like a good idea, and watched your memory usage spike into the stratosphere. ZFS loves RAM. It treats the ARC as a bottomless pit, which is usually fine until a heavy backup job kicks in and decides it needs to pull the entire dataset into memory for verification. Suddenly, your production database is swapping to disk and the kernel is invoking the OOM killer on your most important processes.

Why the ARC refuses to share

The Adaptive Replacement Cache is clever, but it doesn’t care about the rest of your server. If you leave it at the default, it will happily consume almost all physical memory. When memory pressure hits, the kernel tries to reclaim space, but ZFS is often too slow to yield, leading to latency spikes that look like hardware failure. If you are running services that aren’t ZFS, you have to put ZFS on a diet.

echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

• Cap the ARC size to 50 percent of your physical RAM for a balanced system.
• Set the value in bytes, not megabytes, as the kernel parameter requires absolute precision.
• Persist the setting by adding it to /etc/modprobe.d/zfs.conf or your systemd module config.

Verify before you crash

Don’t just trust that the command worked. Check the arcstat utility or look at the slabinfo in /proc/meminfo. If you find your system is still thrashing, check if you have inadvertently left recordsize set to something tiny on a large file workload, which bloats the metadata and forces more caching. Tune this during off-hours unless you enjoy explaining to your boss why the whole stack went sideways at 2 PM.