LINUX.ORG.RU
ФорумAdmin

Высокая нагрузка CPU bind-chroot

 , , , ,


0

1

Добрый день!

Кто-нибудь сталкивался с тем, что bind9 (в chroot'e) сильно нагружает CPU? Сам сервис располагается на виртуальной машине в VMware ESXi 5.5 с 4 ядрами и 4Гб оперативы, OS - RHEL 7.3, версия bind'a - 9.9.4-38.el7_3.3. Пользователей около 45 тысяч. Помимо самого bind'a на сервере есть еще quagga для работы anycast'a по bgp. Утром и днем load average 1.2-1.8, вечером доходит до 3, почти все ядра грузятся более чем на 50%. Вечернее усиление нагрузки оправдывается тем, что все пользователи начинают активно пользоваться домашним Интернетом, но даже это я думаю не оправдывает такой нагрузки на CPU. Почему может происходить такая нагрузка или все же это нормальное явление? Все лишнее закрыто фаерволом, в конфиге bind'a есть acl'ки для «view-зон», так же левым сетям он отвечать не будет.

По мимо bind'a много процессорного времени занимают процессы ksoftirqd и rcu_sched, но сама нагрузка от них на процессор минимальна.


Ответ на: комментарий от anonymous
version: 9.9.4-RedHat-9.9.4-38.el7_3.3 (unknown) <id:8f9657aa>
CPUs found: 4
worker threads: 4
UDP listeners per interface: 4
number of zones: 7444
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 76/5400/5500
tcp clients: 0/100
server is up and running

query log как раз-таки включен. Из-за этого так может грузить?

amkgi ()
Ответ на: комментарий от anonymous

Отключил, но сильно не повлияло. В основном load average отображается каким-то скачками из-за bind'a, то он 1.2 и вот уже 2.53, потом 1.5 и так постоянно скачет.

Да,все запросы обрабатываются bind'ом. Кроме него и quagg'и другого софта на сервере нету, но демоны quagg'и никак тоже не грузят ядра.

amkgi ()
Ответ на: комментарий от imul

Сами логи до 5 мб, а далее перезаписываются.
Вот кусок из конфига для логов:

channel queries_file {
        file "/var/log/queries.log" versions 3 size 5m;
        severity dynamic;
        print-time yes;

amkgi ()
Ответ на: комментарий от imul

И сколько за сутки набегает по размеру?

У меня как-то так:

# bzcat bind_queries.1.bz2|wc -l
13023882

Bind тоже в chroot, но не в виртуалке. Особо как-то не грузит этот query log. Старенький P4 3 GHz, одно ядро с гипертредингом. Один HDD. Хотя вопрос, на сколько больше запросов у ТС...

AS ★★★★★ ()
Ответ на: комментарий от anonymous

Хотя после отключения querylog, loadavg опускается теперь до 0.5 (ранее такого не было), но происходят скачки все равно до 2.5

amkgi ()
Ответ на: комментарий от amkgi

Хотя после отключения querylog, loadavg опускается теперь до 0.5

Кстати, а ОЗУ сколько ? И на сколько и чем занято ?

AS ★★★★★ ()
Ответ на: комментарий от AS

Хотя вопрос, на сколько больше запросов у ТС...

Cейчас tcpdump'ом снял количество запросов по 53, приходящих на один из аникастовых IP этого сервере, за 60 секунд прилетело - 214786 запросов

Кстати, а ОЗУ сколько ? И на сколько и чем занято ?

Серваку выделено 4 Гб, из них сейчас используется 1,7 Гб. Оперативу ничего особо не ест, кроме опять-таки bind'a. Если нагрузка на cpu постоянно прыгает, то оперативу bind всегда стабильно держит занятой на 42%
Вот пример из top'a :

top - 14:33:20 up 30 days, 22:41,  2 users,  load average: 1.65, 1.51, 1.45
Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
%Cpu0  :  7.6 us,  9.0 sy,  0.0 ni, 83.1 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu1  : 11.3 us, 13.7 sy,  0.0 ni, 65.1 id,  0.0 wa,  0.0 hi,  9.9 si,  0.0 st
%Cpu2  :  9.2 us, 12.0 sy,  0.0 ni, 74.0 id,  0.0 wa,  0.0 hi,  4.8 si,  0.0 st
%Cpu3  : 11.7 us, 12.4 sy,  0.0 ni, 71.2 id,  0.0 wa,  0.0 hi,  4.7 si,  0.0 st
KiB Mem :  3882052 total,  1677304 free,  1815456 used,   389292 buff/cache
KiB Swap:  2097148 total,  2097148 free,        0 used.  1617376 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9436 named     20   0 1929628 1.581g   3476 S  93.7 42.7   1515:57 named
Cейчас кстати если смотреть то проц хотя бы не более 100% грузится (после отключения querylog), но все равно проблема высокой нагрузки сохраняется и есть скачки до 2.8

amkgi ()
Ответ на: комментарий от amkgi

и есть скачки до 2.8

Вообще-то, если LA не превышает количества честных ядер, до это нормально. Если там гипертрединг, то надо чуть поменьше.

AS ★★★★★ ()
Ответ на: комментарий от amkgi

зон много, клиентов много, что вы хотите. если idle ядер не падает ниже 50% можно забить. далее только переносить рекурсию, например, на unbound. 70+ ожидающих рекурсию это не мало.

anonymous ()
Ответ на: комментарий от AS

Это я знаю. Но все равно, я и ранее у других провайдеров админил dns'ы, были по мимо bind'a и unbound, и powerdns. Кол-во пользователей было меньше (но не намного) и там выше 0,5 loadavg никогда не поднимался, тут добавилось только ± 5000 тыс пользователей и split horizon.

amkgi ()
Ответ на: комментарий от anonymous

Ок, тогда не буду заморачиваться, idle в среднем всегда 70%. На unbound хотелось бы перейти, но у него я не нашел поддержки split horizon (или GeoIP). Зоны, которые есть на этом DNS'e служат только для работы внутри сети провайдера, некоторые из них допустим используются для установки Интернет-соединения разных регионов (то бишь если пришел запрос с такого-то IP, выдать ему такой ответ, если с другого то другой и это все по одному и тому же домену), другие для предоставления тех или иных услуг (так же с ротацией по регионам).

amkgi ()

Кстати, кто-нибудь может подсказать насчет этого значения:

number of zones: 7444
Это реальное количество файлов с зонами? Но у меня нет их столько там, там всего их 129. Или это значение понимается как-то иначе?

amkgi ()
Ответ на: комментарий от amkgi

Сами логи до 5 мб, а далее перезаписываются.

Ок, тогда сколько файлов наматывается за сутки?
I/O в виртуалках далеко не самое широкое место.

imul ★★★★★ ()
Ответ на: комментарий от AS

У меня просто query log выключен. Пишу только error и security violations.

Хотя вопрос, на сколько больше запросов у ТС...

От 45 тысяч пользователей у ТС наверное очень много запросов.

bzcat bind_queries.1.bz2|wc -l
13023882

Это всего 151 запрос в секунду в среднем. Пень третий намного больше выдержит.

imul ★★★★★ ()
Последнее исправление: imul (всего исправлений: 1)

Query logging в бинде, даже если он идет в null канал, сильно снижает скорость. Поэтому его надо выключать совсем чтобы в rndc status он был OFF.

blind_oracle ★★★★★ ()
Ответ на: комментарий от imul

Не много, в основном они перезаписываются, бывает что иногда происходит ротация с отдельными логами, создаются до 4-5 файлов создаются с порядковыми номерами в конце.

amkgi ()
Ответ на: комментарий от blind_oracle

Я убрал на всех ns'ах строчку с логированием. Хоть не на много, но действительно нагрузка спала.

amkgi ()
Ответ на: комментарий от imul

К сожалению, я уже отключил логирование и включать его уже не хочется)

amkgi ()

Кто-нибудь знает, влияет ли раздробленность конфига named.conf на скорость самого dns?

У меня слишком большой конфиг и я бы хотел разбить его на несколько файлов, используя потом include в конфиге.

amkgi ()
Ответ на: комментарий от amkgi

100% не дам, но вроде как не с чего влиять, да конфиг при загрузке только читается.

anc ★★★★★ ()
Ответ на: комментарий от amkgi

Вот кусок из конфига для логов:

Уже поздно, раз отключил, да и количество запросов у тебя сильно больше, но что-то я про одну штуку совсем забыл. А кто syslog ? Я syslog-ng использую. Его можно так настроить, чтобы он не сразу полученное на диск писал, а копил какое-то время.

AS ★★★★★ ()
Ответ на: комментарий от AS

rsyslog, если речь идет об этом) стороннего я ничего не ставил. Да и честно говоря, лог bind'a мне не нужен уже. В нем была необходимость только на момент ввода в эксплуатацию этих серверов, чтобы отследить идет ли правильно маршрутизация по anycast'у на эти сервера.

amkgi ()
Ответ на: комментарий от amkgi

rsyslog, если речь идет об этом) стороннего я ничего не ставил.

Да, про это. Про rsyslog не скажу, это надо посмотреть, что он умеет в плане минимизации нагрузки по записи.

Да и честно говоря, лог bind'a мне не нужен уже

Ну может ещё для чего большой поток логов потребуется.

AS ★★★★★ ()

Недавно наткнулся на утилиту dnstop (не совсем еще в ней разобрался, надеюсь кто подскажет) и она показала мне интересный вывод если нажать на клавишу «с»:

Source  uery Name              Count      %   cum%
------- ------------------ --------- ------ ------
2.2.2.2 amazonaws.com            275    0.5    0.5
2.2.2.2 akamaiedge.net           229    0.4    0.9
2.2.2.2 akamai.net               207    0.4    1.3
2.2.2.2 mail.ru                  155    0.3    1.9
2.2.2.2 googlevideo.com          153    0.3    2.1
2.2.2.2 cloudfront.net            92    0.2    2.3
2.2.2.2 akadns.net                91    0.2    2.5
2.2.2.2 sugarpulse.com            89    0.2    2.6
2.2.2.2 apple-dns.net             79    0.1    2.8
2.2.2.2 - это ip моего сервера (ненастоящий, я его здесь заменил). Отсюда видно, что он постоянно спрашивает у себя эти домены и вопрос зачем??? Первые 5 доменов вообще победители по запросам, он чуть ли не каждую милисекунду их опрашивает. Сами запросы от клиентов не столь значительны. Ну доспустим вот для примера (это вывод без нажатия клавиши «с»):
Sources             Count      %   cum%
--------------- --------- ------ ------
2.2.2.2              7697   10.2   10.2
10.65.169.37          511    0.7   10.9
10.65.55.87           174    0.2   11.1
10.47.110.105         171    0.2   11.4
10.46.30.55           156    0.2   11.6
10.65.195.58          151    0.2   11.8
10.45.64.88           150    0.2   12.0
10.46.182.43          146    0.2   12.2
10.47.152.118         140    0.2   12.4
10.47.58.50           128    0.2   12.5
Это запросы за 15 секунд, он самому себе прислал 7697 запросов. Вопрос: для чего он это делает или мне не стоит заострять на этом внимание?

Если же я эту утилиту запускаю с ключем "-l 3" для того, чтобы посмотреть запросы по доменам 3-го уровня и дополнительно использую ключ, чтоб он отобразил мне источники, то там запросов от самого сервера я не вижу, да и через tcpdump я смотрел сам себе сервер не шлет запросы. Напомню, что 2.2.2.2 это адрес самого сервера, запросы по dns идут на anycast'овый IP, который свешан на «lo» и отличается от этого IP.

amkgi ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.