ZFS arc_max isn’t a silver bullet for your OOM killer woes

Technical Briefing | 7/13/2026

You probably set zfs_arc_max when you first provisioned your storage server, assuming that capping the ARC would keep the system healthy. But if you have ever seen your application process vanish into thin air without a kernel panic, you have likely run into the gap between the ARC and the wired memory the kernel actually holds onto. The ARC reports itself as cache, but under heavy pressure, it doesn’t always yield the memory fast enough to stop the OOM killer from swinging its axe at your production database.

Where the memory is actually hiding

When ZFS takes memory, it takes it as kmem_alloc. If your ARC limit is high and the system is churning through small random reads, the fragmentation in that memory pool can get gnarly. You might check free memory and see gigabytes available, yet the kernel is already panicking because it cannot allocate a contiguous block for a critical task. Relying on the ARC reported in htop is misleading because it ignores the overhead of the DMU and the SPA buffers that aren’t strictly classified as cached data.

arcstat 1
echo 2147483648 > /sys/module/zfs/parameters/zfs_arc_max

• Monitor the arc_meta_used statistic to see how much metadata is bloating your wired memory
• Watch out for the zfs_arc_meta_limit which defaults to a quarter of your RAM
• Tune the arc_prune_interval if your system is doing heavy snapshot replication during peak hours

Before you just keep cranking down your ARC limit, check if you have ARC metadata bloat. If you have millions of small files, your metadata footprint will swallow your memory before the file data ever gets a chance. If you keep hitting the OOM killer, force an ARC cleanup using the tunable and monitor /proc/spl/kstat/zfs/arcstats to see if the reclaim efficiency is actually moving. Just don’t let it stay too low, or your read performance will tank so hard your users will start filing tickets.