ZFS ARC Tuning for TrueNAS: When (and When Not) to Adjust It

Why ZFS ARC Using Most of Your RAM is By Design (and Not a Problem)

If you’ve just set up TrueNAS and glanced at the dashboard, you’ve probably seen a shocking number: RAM usage at 80%, 90%, or even 95% with barely any data stored. Your first instinct might be to search for “zfs arc tuning” to fix what looks like a memory leak. Stop right there. That high memory usage is the ZFS Adaptive Replacement Cache (ARC) doing exactly what it’s designed to do — using idle RAM to cache frequently accessed data for faster reads.

ARC is not a memory leak. It’s a smart read cache that dynamically expands to fill available RAM, then releases it instantly when applications or VMs need it. The TrueNAS dashboard shows ARC as “used” memory, but the kernel treats it as available. This is the same behavior you’d see with Linux’s page cache, just much more aggressive and effective. Before you change any zfs_arc_max settings, understand that the default behavior is correct for 90% of homelab setups.

When Raising the ARC Limit Helps: Storage-Only Boxes

If your TrueNAS server is a pure storage appliance — no VMs, no Docker containers, no jails running Plex or other apps — then raising the ARC limit can improve read performance. The default ARC size is capped at 50% of total system RAM (or up to 90% on some builds). For a storage-only NAS with 32 GB of RAM, the ARC might max out at around 16 GB. If you have frequently accessed datasets (media libraries, ISO archives, database backups), increasing zfs_arc_max to 24 GB or even 28 GB can reduce disk reads noticeably.

This scenario applies to dedicated backup targets or media servers where the OS has no competing memory demands. You can safely set zfs_arc_max to 80-90% of total RAM. Use the TrueNAS web UI under System → Tunables to add a sysctl with variable vfs.zfs.arc_max and a value in bytes (e.g., 25769803776 for 24 GB).

Why Running VMs and Docker Apps Means Leaving ARC at Default

Once you introduce VMs or Docker containers, the memory competition changes everything. A VM running a database or a Docker container hosting Nextcloud needs predictable, guaranteed RAM. If you’ve set zfs_arc_max to 90% of your 32 GB system, you’ve left only 3.2 GB for VMs and the TrueNAS kernel. That’s not enough for even a single lightweight VM with 2 GB allocated.

The default ARC behavior — dynamically shrinking when other processes need memory — handles this perfectly. TrueNAS and FreeBSD’s memory management are designed for this exact scenario. If you manually cap ARC to a low value (e.g., 4 GB on a 32 GB system), you’re wasting RAM that could be used for caching, and you’ll see slower reads from your pools. The Best Docker Server Build 2026 guide recommends leaving ARC at default when containers share the same hardware.

The “Don’t Touch It for the First Month” Rule

Before you change any ARC settings, run your TrueNAS with default configuration for at least 30 days. This isn’t a delay tactic — it’s the only way to collect meaningful data on your actual workload. During this month, monitor three things:

• ARC hit ratio — run arc_summary in the shell. A ratio above 85% means ARC is working well. Below 70% might indicate you need more RAM or an L2ARC.
• Actual memory pressure — check top or the TrueNAS reporting dashboard. If VMs or apps never encounter OOM errors, ARC tuning is unnecessary.
• Read latency — if your pool shows high average latency on reads (above 10ms for SSDs, above 30ms for HDDs), ARC might be undersized.

Most homelab users who panic and tune ARC immediately never actually hit a performance bottleneck. They see the high memory usage in the GUI and assume something is broken. After 30 days, if your ARC hit ratio is below 75% and you have consistent free memory (not just ARC-reclaimable memory), then and only then should you consider adjusting zfs_arc_max upward.

When L2ARC Is Actually Justified (and When It’s a Waste)

L2ARC is a second-level cache stored on a fast SSD (NVMe or SATA SSD). It extends the ARC by caching data that doesn’t fit in RAM. The common mistake is buying an L2ARC SSD before maxing out RAM. This is almost always the wrong order. L2ARC has overhead — it uses a small amount of RAM (about 1 GB per 100 GB of L2ARC) to index the cache. If your RAM is already insufficient, L2ARC makes the problem worse by consuming more of it.

L2ARC is justified only when:

• You’ve already installed the maximum RAM your motherboard supports (or your budget allows).
• Your ARC hit ratio remains below 70% despite having 32 GB or more of RAM.
• Your workload has a large working set that doesn’t fit in RAM — for example, a media library of 4 TB where users frequently access different files.

For a typical 4-bay home NAS with 16 GB of RAM and a few TB of media, L2ARC adds complexity and power draw for marginal gain. The How Much Does It Cost to Run a NAS? calculator shows that an L2ARC SSD adds $5-15 per year in electricity, plus the upfront cost of the drive. That money is better spent on more RAM first.

How to Tune ZFS ARC Max Safely

If you’ve determined that manual tuning is needed (storage-only box with confirmed low hit ratio), here’s the safe procedure:

For reference, ZFS snapshots interact with ARC in a specific way — snapshots themselves don’t consume ARC, but the data blocks they reference do. If you’re using ZFS Snapshots Explained: A Homelab Guide to Instant Rollbacks, ARC will cache the active blocks of your datasets, not the snapshot metadata.

ARC and RAID: How Pool Layout Affects Cache Behavior

The RAID level you choose also influences how effective ARC is. With RAID 5 vs RAID 6, parity calculations add CPU overhead, but ARC reduces the number of read operations needed. A RAID 6 array with 8 drives benefits more from a large ARC than a RAID 10 array, because parity reads are more expensive. Similarly, RAID 1 vs RAID 5 comparisons show that mirroring (RAID 1/10) has lower read latency, meaning ARC has less impact — the drives can serve data faster even without a cache hit. Note that RAID is not a backup; always maintain separate backups of critical data.

In practice, if you’re running RAID 5 or RAID 6 on spinning hard drives, a well-sized ARC (16-32 GB) can reduce average read latency by 60-80% for frequently accessed files. For RAID 10 with SSDs, the benefit is smaller — often just 10-20% — because the underlying storage is already fast enough.

Bottom Line: When Should You Tune ZFS ARC?

Adjust zfs_arc_max only if your TrueNAS is a dedicated storage server with no VMs or containers, you’ve confirmed a low ARC hit ratio (<70%) after 30 days of monitoring, and you have at least 16 GB of RAM. For everyone else — especially anyone running Docker, VMs, or any application on the same host — leave ARC at its default setting. The TrueNAS memory management is smarter than manual tuning for mixed workloads.

If you’re on a tight hardware budget, prioritize RAM over L2ARC. An extra 8 GB of RAM costs $20-40 and will improve ARC performance far more than a $60 NVMe drive used as L2ARC. Use the How Much Does It Cost to Run a NAS? guide to compare total cost of ownership before buying cache hardware.

Frequently Asked Questions