Proxmox defaults set zfs_arc_max to 50% of system RAM, capped at 16 GiB. On a 64 GiB home lab host running four VMs, that’s rarely what you actually want, and the wrong value here silently starves your VMs of RAM the second an ARC-heavy backup kicks off. The best apps for tuning ZFS ARC cache on desktop and home-lab servers give you the two things you need to make the call: current hit rate, and headroom-aware sizing.
We tested seven picks, all runnable on Linux (where OpenZFS actually lives), several with Windows and macOS clients for the dashboard side. Six are free. All seven pair well with a Proxmox home lab.
What to look for
Every tool in this list has to answer three questions for your ARC tuning:
- What’s the ARC hit rate right now? Below 80% and your cache is undersized. Above 98% and you may be over-allocating RAM that a VM could use.
- What size should ARC actually be? Rule of thumb: reserve VM allocations plus 2 to 4 GiB for the Proxmox host, and the rest is your ZFS budget. Start at 6 to 10 GiB on a 64 GiB host.
- How is the ARC being pressured? MFU vs MRU eviction rates, prefetch stats, and L2ARC hit ratio if you have one.
The picks split into three groups: CLI tools that ship with OpenZFS, dashboards that visualize the CLI data, and orchestration tools that manage ARC state alongside snapshots.
Quick comparison
| App | Best for | Platforms | Free plan | Starting price | License |
|---|---|---|---|---|---|
| arc_summary | Detailed ARC breakdown | Linux, FreeBSD, macOS | Yes | Free | CDDL |
| arcstat | Real-time ARC monitoring | Linux, FreeBSD | Yes | Free | CDDL |
| zpool iostat | Pool-level I/O stats | Linux, FreeBSD, macOS | Yes | Free | CDDL |
| Cockpit | Web dashboard for Proxmox alt | Linux | Yes | Free | LGPL |
| Netdata | Real-time ARC graphs | Linux, macOS, FreeBSD | Yes | Free tier | GPL / cloud |
| Prometheus + Grafana | Full historical dashboards | Linux, cross-platform UI | Yes | Free | Apache 2 |
| Sanoid | Snapshot + ARC coordination | Linux | Yes | Free | GPLv3 |
1. arc_summary – Best detailed ARC breakdown
arc_summary ships with OpenZFS and is the single most useful command for ARC tuning. Running arc_summary prints hit ratio, MFU vs MRU balance, prefetch effectiveness, and L2ARC status all in one report. On Proxmox VE 8.x and 9.x it’s already installed.
Where it falls short: CLI only. No historical data (it’s a snapshot of “right now”).
Pricing:
- Free: Yes, ships with OpenZFS.
- Paid: None.
Platforms: Linux, FreeBSD, macOS wherever OpenZFS is installed.
Download: Included in the zfsutils-linux package on Debian/Proxmox. See openzfs.org.
Bottom line: Start every tuning session by running this. Everything else is optional.
2. arcstat – Best for real-time ARC monitoring
arcstat is the real-time companion to arc_summary. Running arcstat 1 gives you a per-second view of hit ratio, MRU/MFU hits, and demand-hit percentage. Perfect for watching the effect of an ARC size change land in real time.
Where it falls short: CLI only. Column-heavy output takes a few reads to make sense of.
Pricing:
- Free: Yes, ships with OpenZFS.
- Paid: None.
Platforms: Linux, FreeBSD.
Download: Included in the zfsutils-linux package.
Bottom line: Best pick for confirming an ARC tuning change actually helped, immediately.
3. zpool iostat – Best pool-level I/O stats
zpool iostat rounds out the CLI trio. Where arc_summary and arcstat cover cache, zpool iostat shows the pool underneath: read/write ops, bandwidth, and latency per vdev. That’s how you distinguish “ARC is undersized” from “the pool itself is slow.”
Where it falls short: CLI only. Requires you to interpret latency numbers.
Pricing:
- Free: Yes.
- Paid: None.
Platforms: Linux, FreeBSD, macOS.
Download: Included with OpenZFS.
Bottom line: The tool that tells you whether tuning ARC will actually help, or whether your bottleneck is elsewhere.
4. Cockpit – Best web dashboard for Proxmox alt
Cockpit is Red Hat’s web-based server dashboard, and its ZFS plugin exposes ARC status, pool health, and dataset properties through a browser UI. If you run TrueNAS SCALE, Cockpit is the natural web console for non-TrueNAS hosts.
Where it falls short: Not as polished as TrueNAS’s web UI. ZFS plugin coverage is basic compared to CLI depth.
Pricing:
- Free: Yes.
- Paid: None.
Platforms: Linux (server). Any browser (client).
Download: cockpit-project.org
Bottom line: Best pick if you want a web UI that isn’t Proxmox’s own.
5. Netdata – Best for real-time ARC graphs
Netdata collects hundreds of metrics per second and its ZFS module renders ARC hit ratio, size, and eviction rates as real-time streaming charts. The free tier runs entirely on your machine and never phones home. The cloud tier is optional for multi-host aggregation.
Where it falls short: Aggressive default polling can measurably add CPU load on low-power hosts. Cloud features are the paid path.
Pricing:
- Free: Full local install, per-node.
- Paid: Netdata Cloud plans start free with paid tiers for teams.
Platforms: Linux, FreeBSD, macOS.
Download: netdata.cloud
Bottom line: Best pick if you want real-time streaming ARC graphs without setting up Prometheus and Grafana yourself.
6. Prometheus + Grafana – Best for full historical dashboards
Prometheus + Grafana is the industry-standard combo for historical monitoring. The zfs_exporter community project scrapes ARC and pool stats, Prometheus stores them, and Grafana renders them with dashboards you can share (or pull from the community).
Where it falls short: Setup is not one-command. You are running three services (exporter, Prometheus, Grafana) and configuring retention.
Pricing:
- Free: Everything.
- Paid: Grafana Cloud has a free tier and paid tiers.
Platforms: Linux for the collectors; browser (Windows, macOS, Linux) for Grafana.
Download: prometheus.io, grafana.com, github.com/pdf/zfs_exporter
Bottom line: Best pick if you want to track ARC hit rate over months, not minutes.
7. Sanoid – Best for snapshot and ARC coordination
Sanoid manages ZFS snapshots, and its Syncoid companion handles replication. Neither directly tunes ARC, but Sanoid’s schedule shapes ARC pressure: an aggressive snapshot cadence generates cache churn. Reading Sanoid’s config next to your ARC hit rate is how you catch “our ARC is fine except at 2am when snapshots hit.”
Where it falls short: Not an ARC tool itself. Only useful as part of a full ZFS operational picture.
Pricing:
- Free: Yes, GPLv3.
- Paid: None.
Platforms: Linux.
Download: github.com/jimsalterjrs/sanoid
Bottom line: Pick this if your ARC hit rate is fine most of the day but tanks during snapshot windows.
How to pick the right one
- Start every tuning session with:
arc_summaryandarcstat 1. Nothing else replaces those. - If you want a web UI on a non-Proxmox host: Cockpit.
- If you want streaming real-time graphs with almost no setup: Netdata.
- If you want historical graphs across months and multi-host aggregation: Prometheus + Grafana with the ZFS exporter.
- If your ARC hit rate tanks at specific times of day: Sanoid, to check whether snapshots are the cause.
- If you’re on TrueNAS SCALE: TrueNAS’s built-in dashboards cover most of this. Reach for CLI tools only when the dashboards can’t answer a specific question.
- If you’re on Proxmox VE 8.x or 9.x: everything above works. Start with
arc_summarysince it’s already installed.
FAQ
What’s the right size for ZFS ARC on Proxmox?
Reserve RAM for your VMs and Proxmox itself (2 to 4 GiB), and give ZFS what’s left. On a 64 GiB host running two 24 GiB VMs, that’s about 12 GiB for ARC. Start conservative and grow if arc_summary shows hit rate below 80%.
How do I set zfs_arc_max on Proxmox?
Create /etc/modprobe.d/zfs.conf with the line options zfs zfs_arc_max=BYTES, then run update-initramfs -u and reboot. Replace BYTES with your chosen value in raw bytes.
Is L2ARC worth it?
Only if your ARC hit ratio is already above 90% and you’re seeing frequent misses. Below that, you want more RAM for the primary ARC. If the L2ARC hit rate stays below 20%, the SSD slots are better used for a special vdev or a pool mirror.
What’s arc_summary and how do I run it?
arc_summary is a CLI script that ships with OpenZFS. Run it as root in the Proxmox shell. It prints a full ARC report including hit ratio, MFU vs MRU balance, and L2ARC status.
Why is my Proxmox VM slow after a big backup?
Almost always ARC eviction pressure. The backup pulls large amounts through the cache and evicts the hot VM data, so the next VM read is a slow pool hit. Watch arcstat 1 during the backup to confirm.
