Как сделать понимаете журналы dnsmasq?
У меня на сервере установлен dnsmasq, и он активно используется. У меня есть следующий журнал dnsmasq в / var / log / syslog при получении сигнала "SIGUSR1"
Jul 16 13:45:50 server1 dnsmasq[427008]: time 1531748750
Jul 16 13:45:50 server1 dnsmasq[427008]: cache size 10000, 18355/597070 cache insertions re-used unexpired cache entries.
Jul 16 13:45:50 server1 dnsmasq[427008]: queries forwarded 1510313, queries answered locally 15347110
Jul 16 13:45:50 server1 dnsmasq[427008]: queries for authoritative zones 0
Jul 16 13:45:50 server1 dnsmasq[427008]: server 100.1.2.3#53: queries sent 242802, retried or failed 0
Jul 16 13:45:50 server1 dnsmasq[427008]: server 100.2.3.4#53: queries sent 1371704, retried or failed 0
Я установил размер кэша на 10000, что составляет максимально допустимое значение. Приложение, которое использует для запроса dnsmasq, также работает медленно. Как понять журнал dnsmasq и узнать, представляют ли эти журналы проблему производительности из-за малого размера кеша?
Перед этим ответом я должен подчеркнуть, что я не особо разбираюсь в dnsmasq, но журналы, объединенные со страницей руководства, кажутся довольно ясными:
Когда он получает SIGUSR1, dnsmasq записывает статистику в системный журнал. Он записывает размер кеша, количество имен, которые должны были быть удалены из кеша до истечения срока их действия, чтобы освободить место для новых имен, и общее количество имен, которые были вставлены в кеш. Также указывается количество попаданий и промахов в кеш, а также количество ответов на авторитетные запросы. Для каждого вышестоящего сервера указывается количество отправленных запросов и количество, которое привело к ошибке. В режиме --no-daemon или когда включено полное ведение журнала (-q), делается полный дамп содержимого кеша.
Итак, учитывая вашу строку:
размер кеша 10000, 18355/597070 вставок кеша повторно использовано, не истекло записи кэша.
Эта строка немного сбивает с толку, но, учитывая приведенный выше текст, я понимаю, что до истечения срока необходимо было удалить 18355 записей, чтобы освободить место для новых записей, а 597070 - это общее количество вставок. Учитывая, что оба эти числа намного больше, чем ваш кеш, больший кеш, вероятно, принесет некоторую пользу, однако разработчики по уважительной причине ограничили бы его значением 10000. Вероятно, он не будет хорошо масштабироваться, даже если вы можете его увеличить, поэтому, если вам действительно нужен больший кеш, вы можете использовать неправильный инструмент.
16 июля 13:45:50 server1 dnsmasq [427008]: запросы перенаправлены 1510313, запросы даны локально 15347110
На большинство ваших запросов ответят локально (с коэффициентом 10), что хорошо, однако эти цифры намного превышают использование кеша. На мой взгляд, это говорит о том, что многие ваши запросы по какой-то причине не кэшируются.
Это может быть связано с тем, что у многих записей TTL, например, равен нулю (например, записи DHCP часто имеют нулевое значение ttls).
Вкл. с другой стороны, один из 10 запросов, который должен быть получен с удаленного сервера, может объяснить воспринимаемую медлительность. Однако это невозможно сказать по предоставленной информации.
Кроме того, даже если все ваши запросы были кэшируемыми, вы, похоже, все равно полностью утилизировали кеш, учитывая количество записей, которые были исключены до истечения срока действия (хотя это зависит от рабочей нагрузки, "пакетный" шаблон может вызвать большое количество выселений).
16 июля 13:45:50 server1 dnsmasq [427008]: сервер 100.1.2.3 # 53: запросы отправлены 242802, повторные попытки или неудачные 0
16 июля 13 : 45: 50 server1 dnsmasq [427008]: server 100.2.3.4 # 53: запросы отправлены 1371704, повторные или неудачные 0
Эти строки показывают, что 100.2.3.4 получает намного больше запросов от вашего сервера dnsmasq, чем 100.1.2.3. Вероятно, это не причина проблемы, но тем не менее интересно.
В качестве примечания: если это те адреса, которые вы действительно используете, и они являются адресами локальной сети, вы можете рассмотреть возможность их изменения. 100.0.0.0/8 - это общедоступный маршрутизируемый блок, поэтому у вас может быть запутанный маршрутизатор, пытающийся маршрутизировать ваши DNS-запросы извне. Даже если вы поместите статические маршруты во все свои маршрутизаторы, это все равно плохая практика, поскольку пользователь вашей сети не сможет получить доступ к чему-либо в Интернете в этом диапазоне.