Don’t let ZFS ARC turn your RAM into a black hole

Technical Briefing | 10/22/2026

You probably noticed that ZFS loves RAM. It eats everything it can get its hands on for the ARC cache. On a dedicated storage server, that is fine. But if you are running other services on the same host, the OOM killer will eventually come for your application processes because the ZFS ARC didn’t want to yield the memory fast enough. I have seen this silently kill production databases more times than I care to admit.

Capping the growth before the kernel panics

The defaults are based on total system RAM, which ignores the reality of multi-tenant workloads. If you do not explicitly clamp the ARC, you are just waiting for a memory pressure spike to take your site offline. Setting a hard limit in your module parameters is the only way to keep the peace between your filesystem and your application processes.

echo 'options zfs zfs_arc_max=8589934592' > /etc/modprobe.d/zfs.conf

• 8GB is a sane starting point for general purpose servers
• Keep zfs_arc_min set to something low to allow system recovery
• Changes require a reboot to take effect on most distros
• Verify your actual usage with arcstat before and after the change

If you have already applied these settings and the kernel is still complaining, double-check your slab overhead. Sometimes ZFS keeps hold of caches that aren’t technically ARC but are still memory-resident. Keep an eye on /proc/spl/kstat/zfs/arcstats if you want to see exactly where your memory is hiding before you get another alert at 3 AM.