Есть шлюз на FreeBSD 9.2. На нём стоит DNS-сервер вышеозначенной версии, обрабатывающий resolve-запросы компьютеров домашней сети и редиректящий сайты с собственного веб-сервера на его внутренний IP (дабы избежать «мёртвой петли»). Последнее время начал сыпать сообщениями, и, соответственно не отвечать на запросы named-демон. В логах наблюдается следующее:
Apr 5 22:16:41 wall named[16575]: client 192.168.2.10#53756 (xc3.services.livejournal.com): error sending response: not enough free resources
Apr 5 22:16:42 wall named[16575]: client 192.168.2.10#59118 (i.ytimg.com): error sending response: not enough free resources
Apr 5 22:30:57 wall named[16575]: client 192.168.2.10#58735 (counter.rambler.ru): error sending response: not enough free resources
Apr 5 22:30:57 wall named[16575]: client 192.168.2.10#64563 (so-l.ru): error sending response: not enough free resources
Apr 5 23:26:56 wall named[16575]: client 192.168.2.10#64610 (autocontext.begun.ru): error sending response: not enough free resources
Apr 5 23:36:56 wall named[16575]: success resolving 'www.smart-clip.com/A' (in 'smart-clip.com'?) after disabling EDNS
Apr 6 00:02:48 wall named[16575]: client 192.168.2.10#62517 (www.youtube.com): error sending response: not enough free resources
Apr 6 03:05:34 wall named[16575]: client 192.168.2.10#51456 (www.youtube.com): error sending response: not enough free resources
Apr 6 03:27:27 wall named[16575]: client 192.168.2.10#59617 (sync.rambler.ru): error sending response: not enough free resources
Apr 6 17:00:34 wall named[16575]: client 192.168.2.10#52902 (safebrowsing.clients.google.com): error sending response: not enough free resources
При этом зависимости от нагрузки на сеть и используемых мощностей абсолютно нет.Конфиг самый простой:
########################################
# Настройка named
######################################### Параметры
options {
# directory задает каталог конфигурации, в котором
# демон named ищет и хранит файлы DNS.
# /etc/namedb - это символическая ссылка.
directory "/etc/namedb";
# pid-file - это имя файла, в котором
# хранится числовой идентификатор
# основного процесса named.
pid-file "/var/run/named/pid";
# dump-file - это кэш ответов демона named.
dump-file "/var/dump/named_dump.db";
# statistics-file сохраняет статистику и другие
# сведения о запросах
statistics-file "/var/stats/named.stats";
clients-per-query 20;
max-clients-per-query 40;
# Включаем форвардинг с прокси сервера
forwarders {
8.8.8.8;
8.8.4.4;
};
# IP-адреса интерфейсов сервера, на котором будет запущена служба named
listen-on {
127.0.0.1;
192.168.1.1;
192.168.2.1;
};
# Диапазон адресов клиентов, для которых разрешено делать запросы
allow-recursion {
127.0.0.1;
192.168.1.0/24;
192.168.2.0/24;
};
};
logging {
category lame-servers { null; };
};# Корневая зона
zone "." {
type hint;
file "named.root";
};# Прямая локальная зона
zone "localhost" {
type master;
file "master/localhost-forward.db";
};# Обратная локальная зона
zone "127.in-addr.arpa" {
type master;
file "master/localhost-reverse.db";
};zone "site1.ru" {
type master;
file "master/site1.ru";
};
Гугл не дал толкового решения, и добавление параметров «clients-per-query», «max-clients-per-query» если и исправило проблему, то совершенно незначительно.Собственно, что делать?
Как ни странно, попытка по-экспериментировать с пропускной способностью сети в связи с лагами Samba-сервера решила проблему. В sysctl.conf прописал следующее:kern.ipc.nmbclusters=50000
kern.ipc.somaxconn=8192
Судя по всему, повлиял конкретно последний параметр, т.к. по-умолчанию там стоит всего 128 соединений.Пока логи чисты, надеюсь, в будущем положение не изменится.
Рано радовался. Ошибки вновь появились. Но с Самбой проблему удалось решить.
> Рано радовался. Ошибки вновь появились. Но с Самбой проблему удалось решить.прочитай в мане про остальные директивы секции
logging
там кроме леймов много что интересного ) главное не забудь лог запросов выключить если че )))
а вообще по ключевым словам лога гугл весьма щедро раздает ссылки
http://local.com.ua/forum/topic/32758-bind-not-enough-free-r.../