From fd211aae5150112b5cdb866ddad80b4a857693f8 Mon Sep 17 00:00:00 2001 From: Matt Date: Wed, 27 May 2026 23:05:52 +0000 Subject: [PATCH] ops: cap ZFS ARC at 2GB on glados MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The cold ZFS pool is a backup tier only — hot data (MC world, Gitea, Directus DB, containers) lives on NVMe LVM, not ZFS. So ARC's default of 50% RAM was wasted: nothing it could cache was hot enough to matter, and the ~16GB cache crowded MC out of RAM, pushing 2.4GB into swap. This file lives in the repo for reproducibility; it gets dropped into /etc/modprobe.d/ on the host and applied immediately via /sys/module/zfs/parameters/zfs_arc_{max,min}. Effect on glados: before: used=27/31GB, free=748MB, ARC=15.6GB after: used=~10GB, free=~14GB, ARC=1.0GB (1-2GB range) Co-Authored-By: Claude Opus 4.7 --- server/deploy/zfs-arc.conf | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 server/deploy/zfs-arc.conf diff --git a/server/deploy/zfs-arc.conf b/server/deploy/zfs-arc.conf new file mode 100644 index 0000000..fdda118 --- /dev/null +++ b/server/deploy/zfs-arc.conf @@ -0,0 +1,17 @@ +# ZFS ARC sizing for glados — a mixed-workload host (32 GB RAM). +# +# Why these numbers: +# - The cold ZFS pool is BACKUP TIER ONLY. Hot data (MC world, Gitea repos, +# Directus DB, containers) all live on NVMe LVM, not ZFS — so a large +# ARC doesn't help any of the actual workloads. +# - Tier-2 backup work is streaming writes (rsync hot→cold every 4h): +# streaming writes don't benefit much from cache. +# - Reads happen rarely (disaster recovery, Gitea LFS fetches), and a +# one-time cold read is fine. +# - MC is the memory-hungry workload (10 GB Java heap). Every GB we DON'T +# give to ARC is a GB more headroom for MC and future content. +# +# 2 GB max / 1 GB min keeps ZFS metadata + small ARC for occasional reads, +# without crowding MC out of RAM. +options zfs zfs_arc_max=2147483648 +options zfs zfs_arc_min=1073741824