Освобождение памяти zfs arc на FreeBSD
У меня есть машина запущенная FreeBSD, которая подвержена различным рабочим нагрузкам, от интенсивного использования диска до интенсивного использования памяти.
Если осуществляется доступ к большим объемам данных ZFS, то использование проводной памяти может быстро вырасти до 95 ГБ, где есть только Установлено 96 ГБ, что приводит к сбоям процесса и зависанию машины.
Процессы checksetuid и neggrpperp могут запускать это самостоятельно.
в качестве обходного решения, установив для vfs.zfs.arc_max значение Примерно половина системной оперативной памяти предотвращает сбои процессов, однако это также имеет возможную проблему с производительностью, которая иногда была бы оптимальной, если бы система могла выделить больше оперативной памяти для дуги, когда она не требуется для других процессов.
Когда оперативная память требуется для другим процессам кажется, что использование проводной памяти снижается слишком медленно.
security_status_chksetuid_enable и security_status_neggrpperm_enable также установлены в NO, чтобы не заполнять дугу бесполезными вещами.
По сути, есть лучший способ справиться с этим, кроме установка vfs.zfs.arc_max на слегка произвольное значение?
ZFS ARC подлежит автоматическому масштабированию в любой системе, использующей ZFS. Ограничение ARC - это только обходной путь; поведение, которое вы испытываете, было в основном обычным для FreeBSD старше 11.x (однако лично я не видел сбоев - только неэффективное использование памяти); после выпуска 11.0 это поведение было значительно уменьшено (поэтому, если вы используете 10.x или даже 9.x, обновите).Если вы все еще видите это в последней версии 12.x, отправьте сообщение в freebsd-stable @ ML или заполните подробный PR. Я не думаю, что отправка сообщения о проблеме в систему отслеживания ошибок Open-ZFS или ML является уместной. Вы также можете использовать порт sysutils / zfs-stats для сужения того, что происходит внутри части памяти ядра и самого ARC, вас, вероятно, попросят прикрепить результат при обращении к stable @ ML.