На одном из наших подчиненных DNS-серверов BIND, версия bind910-9.10.0P2_3, постоянно убивается следующим сообщением в /var/log/messages:
Jul 30 01:00:10 cinnabar kernel: pid 602 (named), uid 53, was killed: out of swap space
Эта служба работает на виртуальной машине FreeBSD 10.0 в XenServer 6.2, у нее 512 МБ системной памяти.
В данный момент pstat -m -s верните это:
Device 1M-blocks Used Avail Capacity
/dev/ada0p3 512 9 502 2%
Я не думаю, что это проблема подкачки, похоже, утечка памяти, но я не уверен.
РЕДАКТИРОВАТЬ: доступ к информации.
Это один из двух подчиненных DNS-серверов, они хранят только зоны авторитетного сервера и действуют как рекурсивный сервер для внутренних пользователей во внешнем мире. Количество клиентов составляет около 700-1500 одновременных пользователей. Поскольку у нас есть внутреннее пространство / 21 и общедоступное пространство IPv4 / 23 и нет запросов из внешнего мира, порт 53 даже заблокирован брандмауэром для этих машин.
Если у вас есть какой-либо вид мониторинга на этом сервере, было бы неплохо проверить, есть ли какие-либо пики использования памяти прямо во время остановки процессов. Затем вы можете попытаться найти корреляцию с количеством запросов и т. Д.
При этом это может означать, что в системе действительно не осталось памяти, но, скорее всего, Bind запрашивает непрерывную область памяти, фрагментация мешает, и FreeBSD пытается заменить некоторые процессы, чтобы освободить место для этого. Вероятно, он не может поменять местами много страниц, не может выделить и запускает убийцу нехватки памяти.
Если у вас есть место на диске, самое простое решение - добавить дополнительный файл подкачки через файл подкачки (не нужен раздел). В идеале вы должны ограничить размер кеша (по умолчанию для привязки нет неограниченный), как предлагает Хокан, но это может повлиять на производительность. Без дополнительной статистики это действительно сложно сказать. В настоящее время даже домашние маршрутизаторы имеют 512 МБ ОЗУ, поэтому вам следует подумать об увеличении этого (и ограничении кеша) для производственного сервера, обслуживающего 700-1500 одновременных пользователей (что может привести к гораздо большему количеству запросов в секунду, опять же, без дополнительной информации трудно сказать ).
Вы также можете попробовать настроить реализацию malloc с помощью MALLOC_PRODUCTION ручку, но я думаю, что это слишком экстремально перед лицом более простых доступных решений.