VS>> Почему сабж не ограничивает размер ARC? Или я неправильно понимаю VS>> его действие? # top | grep ^ARC VS>> ARC: 938M Total, 633M MFU, 65M MRU, 15M Anon, 9277K Header, 215M VS>> Other # sysctl vfs.zfs.arc_max vfs.zfs.arc_max: 41943040 # VS>> https://wiki.freebsd.org/ZFSTuningGuide читал, это прямо пример VS>> оттуда про vfs.zfs.arc_max="40M"
EG> Это писалось во времена FreeBSD 9.x или раньше и тогда оно работало EG> чётко.
EG> С тех пор код ZFS изменился и теперь это "мягкий лимит", EG> который ZFS нынче легко превышает, например, если метаданные дерева EG> src/ports/obj не влазят в заниженный ARC при ночном запуске periodic EG> daily, который тоже писался до появления ZFS и радостно обходит EG> find'ом всё вокруг.
Мне бы для гипервизора bhyve, а то кажется мне, что этот ARC у виртуалок память отнимает. Впрочем достоверно обосновать не могу.
EG> В частности поэтому на мелких виртуалках я делаю z/src, z/obj и EG> z/ports без автомонтирования и засовываю их в /etc/fstab с EG> noauto, чтобы когда надо, делать просто mount /usr/ports, а потом EG> umount /usr/ports.
Вот на этом хосте с vm-bhyve у меня вообще нет развесистых деревьев с исходниками и портами, а ARC пухнет. VM все живут на zvol.
EG> Теоретически ZFS затем должно освобождать "лишнюю" память, EG> практически до недавнего времени это точно было сломано, EG> но вроде бы потом чинили (не проверял). Есть workaround: EG> завысить vm.v_free_min, но можно переборщить и привести систему EG> в нерабочее состояние.
EG> vm.v_free_min измеряется в 4-килобайтных страницах и на десктопной EG> системе (рабочая станция с иксами) с 8G памяти работает завышение EG> до 131072 (512MB). Смысл завышения в том, чтобы заставить фрёвый EG> pagedaemon пинать ZFS на тему высвобождения памяти не тогда, EG> когда система уже вошла в vm trashing, а сильно заранее.
