ZFS ARC сожрал всю память, OOM killer прибил VM посреди ночи. Как приручить?

[fluxproxy8389]

@perf_freak смотря какой профиль нагрузки. Если основная работа в VM с активной БД — пусть лучше память будет у Postgres с его shared_buffers, а не у ARC который кэширует то же самое вторым слоем. Двойное кэширование тут зло.

[miron_tcp]

@db_admin справедливо для случая базы. Но человек не сказал что у него БД жрёт всё. Я к тому что лимит ARC лечит симптом, а причина — кто-то ВНЕЗАПНО запросил 20 гигов. Это надо найти.

[matvey5196]

Причину нашёл вроде: ночной бэкап-job делал dump базы в tmpfs (да-да, я гений), tmpfs распух, память кончилась, ARC не успел ужаться. Так что виноваты оба фактора.

[vadim_dev77]

О, вот это и есть настоящий корень. tmpfs живёт в RAM, dump на 15 гигов туда — и привет OOM. ARC тут просто оказался самым жирным соседом под раздачу.

[jscode1641]

Ору, классика homelab: чинишь ZFS три страницы, а виноват дамп в tmpfs. Перенеси дамп на сам пул и не выдумывай.

[julia_kernel]

@anton_py всё так. Зато про ARC узнал кучу нового, не зря. Итог: лимит ARC поставил на 16, дамп унёс на nvme-датасет, tmpfs урезал. Третью ночь без OOM, полёт нормальный.

[stas_x]

Сохраняю тред, это идеальный учебный кейс: 'симптом в одном месте, причина в другом'. Спасибо за честное 'я гений' про tmpfs, без иронии — большинство бы постеснялось.

[elena_daemon61]

Подытожу для гугла: 1) лимитируй zfs_arc_max, 2) следи за tmpfs, 3) OOM убивает не виновного а самого жирного, 4) ARC можно резать без страха за данные. Всё, расходимся.

[ruslan_pro]

Согласен с итогом. Снимаю возражение, причина была не в ARC. Хороший разбор, побольше бы таких вместо 'у меня не работает, помогите' без логов.