VS>> May 26 23:32:44 vas kernel: swap_pager_getswapspace(16): failed VS>> и так много-много раз. Как узнать, кто скушал своп, какой VS>> процесс? И почему в конце концов это привело к беде (к повисанию VS>> системы)? 10.3, amd64, ZFS. Прямо сейчас вот смотрю swapinfo, 0% VS>> использовано из 8 Гб свопа.
EG> Hе знаю как щас в bleeding edge и в 11-STABLE, EG> но в 10.3 совершенно точно ZFs ARC может выжрать всю память.
EG> Если нет возможности обновиться хотя бы до 11.1 - всё плохо.
Да почему, есть возможность обновиться, 10-ке в любом случае скоро EoL. В 11.1 что-то починено в этом месте, да?
EG> Пробуй ставить жесткие лимиты на ARC (vfs.zfs.arc_max) и молись,
У меня в /boot/loader.conf уже сто лет стоит vfs.zfs.arc_max="41943040" но почему-то не спасло.
EG> чтобы оно не превышало лимит в слишком много раз и слишком надолго.
Так с чего оно вообще взбесилось вдруг? Я никаких миров и портов не собирал, мирно спал ночью, только раздавал WiFi сыну-полуночнику.
EG> И ещё - там лимит превышается из-за кеширования не столько данных, EG> сколько метаданных. А у нас в periodic есть скрипты, которые EG> писались во время UFS и в случае с ZFS провоцируют ненужное EG> кеширование огромного количества метаданных несколькими запусками find EG> по всему дереву каталогов.
EG> Очень сильно помогает убирание не используемых постоянно каталогов EG> типа /usr/ports, /usr/src и /usr/obj в отдельные файловые системы,
У меня в /usr/ports, /usr/src и /usr/obj девстенно пусто. Что ещё могло дать эффект разрастания и почему vfs.zfs.arc_max="41943040" не помог?
Или может всё же виновник сабже - на этот раз не ZFS?
