ops: cap ZFS ARC at 2GB on glados
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 <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
||||||
Reference in New Issue
Block a user