Most of us treat the ZFS ARC as a black box. You throw RAM at a server, ZFS grabs most of it for caching, and everything feels snappy until the day your main application starts hitting the OOM killer because the kernel decided it needed more pages for block metadata. Watching your database get nuked at 3 AM because the ARC didn’t yield memory fast enough is a rite of passage I would rather you avoid.

Why letting ZFS take the whole pie is a bad bet

ZFS behaves like a greedy tenant. By default, it wants to use half of your system RAM. But if you have other memory-hungry processes like Postgres or Java running on the same host, ZFS won’t play nice when pressure mounts. The kernel tries to reclaim pages, but the ARC’s internal locks often cause latency spikes while the system struggles to shrink the cache. You are better off setting a hard ceiling based on your actual, measured peak load.

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

• Calculate the value in bytes by multiplying your desired gigabytes by 1024 to the third power
• Set the limit in /etc/modprobe.d/zfs.conf so it actually sticks after a reboot
• Use zfs-stats -a or arcstat to monitor if your hit rate tanks after applying the cap

Verification before you ship it

Before you commit this to your configuration management, check how much RAM your ARC is holding right now. If it is already over your target, you might see a brief IO stall while the cache purges. Use the slabtop command to see where the rest of your memory is living, and verify the current module parameter with cat /sys/module/zfs/parameters/zfs_arc_max. Don’t blindly trust your initial calculation—monitor the hit rate over a full backup cycle to ensure you haven’t choked your read performance.