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

Technical Briefing | 10/8/2026

You probably think ZFS is being smart when it starts eating up every spare byte of RAM for its Adaptive Replacement Cache. And usually, you’re right. But I have seen production servers crawl to a halt because the kernel’s memory pressure handler started thrashing the swap partition because the ZFS ARC wouldn’t let go of its cached metadata. It is a classic case of the OS and the filesystem fighting for the same resources.

Why the default behavior bites you eventually

By default, ZFS on Linux is allowed to use up to half of your total system memory for the ARC. This assumes you are running a dedicated storage node. If you are running an application server or a container host, that 50 percent is a massive overreach. When the OOM killer starts eyeing your mission-critical process instead of the filesystem cache, that is a bad day at the office.

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

• Use zfs_arc_max to set a hard ceiling in bytes rather than leaving it to the defaults.
• Check your current usage with arc_summary to see how much of your cache is actually metadata vs raw data.
• Remember that changing this at runtime is temporary; you need a module config file to make it stick across reboots.

If you are managing high-concurrency database workloads, I recommend capping the ARC significantly lower than the default. It is better to have a slightly slower file lookup than to trigger a kernel-level memory stall that takes down your entire service. Set the limit, watch your memory usage for a few days under load, and adjust accordingly. Don’t wait for a midnight paging alert to find out your kernel is swapping its own cache to disk.