Производительность BIND

Бинд вертится в виртуалке в вмварном кластере, тачка его долбящая там же, либо на одном хосте с ним, либо на другом, на результат почти не влияет.

Странно. Т.е. получается что он тормозит больше чем два лишних линка...

бинд 9.9.1 самопал, линупс дебиан стэйбл с ядром 3.0.32

Попробуй родное дистрибутивное ядро, указав в настройках ВМ правильную версию ОС. 90 % проблема в этом. vmware честно затачивает свои драйверы под конкретную версию ОСи. Например для слишком новых нужно специально настраивать vmxnet3:

Poor TCP performance can occur in traffic-forwarding virtual machines with LRO enabled Some Linux modules cannot handle LRO-generated packets. As a result, having LRO enabled on a VMXNET 2 or VMXNET 3 device in a traffic forwarding virtual machine running a Linux guest operating system can cause poor TCP performance. LRO is enabled by default on these devices.

И ещё я бы попробовал дистрибутивный bind

З.Ы. что за dnsperf и где его брать?

погрепал документацию bind. Для улучшения производительности рекомендуется включить

options {
  minimal-responses yes;
}

Но на моём сервере это дало только +15..20% в dnsperf

В виртуалке 8 процов

Попробуй уменьшить количество CPU.

Например подними VM только с BIND и отдай 1-2 vCPU

Форвардинга на этом хосте нет, да и LRO отключается автоматом в ядре уже давно вроде после того как выставлен ip_forward=1 в sysctl. TCP перформанс мерял iperf-ом, всё пучком.

Дистрибутивный бинд дюже древний, да и не думаю что там будут какие-то профиты. Попробую как last resort :)

Да, об этом я тоже думал, помнится мне какие-то статьи про проблемы с шедулингом когда много ядер. Проверю.

Проверил, результат еще хуже: ~40к запросов в сек.

Да, какую-то прибавку оно дало, но в таких же пределах.

Пересобрал с "-O3 -march=core2 -mtune=core2 -fomit-frame-pointer" - нагрузка упала с 650% до 550%, а скорость осталась такая же. Всё чудесатее и чудесатее...

Нашел вот такую доку: https://www.dns-oarc.net/files/workshop-2007/Boggs-DNSPERF.pdf

У людей на серверах 2007 года на генту бинд выдавал почти 100к запросов в секунду.

TCP перформанс мерял iperf-ом, всё пучком.

И? какая пропускная способность если слать кучу мелких (<256 байт) пакеты?

Не вижу, в чем плохо - уменьшили количество vCPU в 4 раза, увидели падение производительности в 1,5 ?

не в коня корм - отдай 1 CPU, хуже не будет. и да, наверняка есть какая-то закавыка в конфигах зоны почему так.

Пересобрал с "-O3 -march=core2 -mtune=core2 -fomit-frame-pointer" - нагрузка упала с 650% до 550%, а скорость осталась такая же. Всё чудесатее и чудесатее...

Есть мнение, что узкое место в kernel space или в работе с сетью

Форвардинга на этом хосте нет, да и LRO отключается автоматом в ядре уже давно вроде после того как выставлен ip_forward=1 в sysctl.

Приводил просто для примера, что для не поддерживаемых официально ядер нужны дополнительные действия

Какая сетевая карта? Сравни обычную и паравиртуальную

По поводу vCPU. Если у тебя не восьмиядерные камни, попробуй уменьшить число vcpu до числа ядер одного процессора.

Ещё в документации по bind сказано, что можно увеличить дефолтный размер памяти под данные и под стек, но дефолтных значений не приводится, так что хз что в этих параметрах писать

Ещё одна мысль. Напиши в рассылку bind-users : вас поимел AD на дефолтных настройках. Листы рассылки ISC

636 мегабит/сек UDP-датаграммами размером 256 байт, судя по айперфу. Это что-то около 310килопакетов в секунду. По-моему, вполне прилично, во всяком случаей в эту цифру не упираемся.

Плохо в том, что DNS AD херачит вдвое быстрее :)

Ну, прирост производительности при добавлении ядер на лицо, но он конечно нифига не линейный.

Сетевуха vmxnet3, железо виртуалки один-в-один как в виртуалке с виндой. Прерывания vmxnet3 раскиданы по ядрам:

root@dm-proxy:/# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:         66          0          0          0          0          0          0          0   IO-APIC-edge      timer
  1:          8          1          0          0          0          0          0          0   IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          1          6          0          0          0          0          0          0   IO-APIC-edge      i8042
 40:       1354        801       1165        431       1600       1491       1413        778   PCI-MSI-edge      vmw_pvscsi
 41:     188433          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-rxtx-0
 42:          9      26534          0          0          0          0          0          0   PCI-MSI-edge      eth0-rxtx-1
 43:         16          0       2491          0          0          0          0          0   PCI-MSI-edge      eth0-rxtx-2
 44:          7          0          0      70069          0          0          0          0   PCI-MSI-edge      eth0-rxtx-3
 45:         56          0          0          0     471682          0          0          0   PCI-MSI-edge      eth0-rxtx-4
 46:         12          0          0          0          0       9372          0          0   PCI-MSI-edge      eth0-rxtx-5
 47:         73          0          0          0          0          0     595322          0   PCI-MSI-edge      eth0-rxtx-6
 48:          6          0          0          0          0          0          0      66172   PCI-MSI-edge      eth0-rxtx-7
 49:          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-event-8
 50:      11500          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-rxtx-0
 51:          6      10200          0          0          0          0          0          0   PCI-MSI-edge      eth1-rxtx-1
 52:          6          0      10254          0          0          0          0          0   PCI-MSI-edge      eth1-rxtx-2
 53:          4          0          0      10322          0          0          0          0   PCI-MSI-edge      eth1-rxtx-3
 54:          1          0          0          0      10363          0          0          0   PCI-MSI-edge      eth1-rxtx-4
 55:          2          0          0          0          0     587415          0          0   PCI-MSI-edge      eth1-rxtx-5
 56:          7          0          0          0          0          0      22787          0   PCI-MSI-edge      eth1-rxtx-6
 57:          9          0          0          0          0          0          0       9954   PCI-MSI-edge      eth1-rxtx-7
 58:          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-event-8
 59:          0          0          0          0          0          0          0          0   PCI-MSI-edge      vmci
 60:          0          0          0          0          0          0          0          0   PCI-MSI-edge      vmci
NMI:          0          0          0          0          0          0          0          0   Non-maskable interrupts
LOC:      92451      75719     101187      89904      82877      52055     428402      95518   Local timer interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0          0          0          0          0   IRQ work interrupts
RES:    1174247    1193025    1164875    1163973    1147379     881161     859430    1117998   Rescheduling interrupts
CAL:        240        207        167        168        547        239        423        350   Function call interrupts
TLB:        939        948        975        615        665        953        911        758   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0          0          0          0          0   Machine check exceptions
MCP:         43         43         43         43         43         43         43         43   Machine check polls
ERR:          0
MIS:          0

На хостах по 2 камня X5650 на 6 ядер в NUMA. 8 это уж я сделал по максимуму, в продакшене будет конечно 6 vCPU, но сути дела это не меняет.

очень вероятно - дело в разной работе драйверов виртаульных езернетов там и там

например на линуксе при получении пакета - система могет дергаться и получать этот пакет
а на винде - может буфер
в результате раное колво переключений - разная потеря на них
и в результате разная latency

тестить сетевую иль дискову производительность в виртуальных средах - это несколько не то

тестируй на реальном железе.

А вообще бинд тормоз, да. Поставь что-нить полегче и долби.

Да, похоже дело в каких-то заковыках виртуалок.

Поставил сейчас через апт-гет бинд 9.8.1 на достаточно старенький HP DL380 G5 (2 x Xeon 5160 @ 3Ghz), там вертится debian testing с штатным ведром 3.2.0

И безо всяких доп. настроек запрашивал у него A-запись для localhost, выдало сразу 80 килозапросов в секунду. Если потюнить, то думаю можно прилично увеличить.

Но всё равно виртуальный жеж AD DNS всех поимел :)

IMHO просто vmware очень сильно точит свою байду под M$.

чего только стоит одна только заточка высфири M$ only.

заточка высфири

для остальных есть CLI?

Да не, это похоже просто бинд дохлый. Попробовал unbound - на железном сервере выдал 160к запросов, на виртуальном - вообще 191к, и это при загрузке CPU 90%.

Так что бинд расстроил, #1 dns server блин :)

unbound есть под оффтоп, производительность не замерял?

Глупость говоришь :), откровенный 4.2. vSphere никто не затачивал исключительно под винду

1) VC и VC client изначально были написаны под винду, кроссплатформенный софт дороже в разработке. Кстати, ПО для управления инфраструкторой RHEV тоже изначально было под винду, сюрприз :) , это сейчас redhat объединился с кучей других компаний и запилили open stack

2) vsphere и VC всегда отлично поддерживали rhel, постеменно добавили debian, ubuntu, centos. Сейчас даже находят время для любителей изврата вроде oracle linux

3) В качестве сервисной консоли для гипервизоров ESX использовался RHEL ; ESXi - тоже *NIX, хотя и сильно обрезанный.

А где ISC говорили, что он №1 по скорости?

Вообще, бинд внутри какашка, так что удивляться «низкой» производительности не стоит. Всё же его столько лет писали...

6 ядер в NUMA

NUMA бы я выключил.

Эээ.. это как? Нума это архитектура сервера с локальной и удаленной памятью, ее не выключишь.

NUMA, это модель использования памяти процессором, которая делает возможным одному CPU лезть в память, «принадлежащую» другому CPU минуя его самого (но с сильно возросшими задержками, по сравнению с локальной).

Обычно отключается в BIOS.

И какой в этом смысл? В таком случае теряется гибкость, каждый процессор, получается, будет ограничен только своей памятью. А если ему надо больше - то хрен тебе? :)

Да и отключение нумы в биосе я думаю просто маскирует данную функциональность от ОС, которые не умеют с ней работать. На деле без нумы оно в принципе не работает.

Ты в этом уверен? :) Расскажи, например, как отключить на банальном proliant'е

NSD нада тогде уже сравнивать, unbound же не авторитативный сервер. Мы вот nsd юзаем, минусов пока не видели.

И какой в этом смысл? В таком случае теряется гибкость, каждый процессор, получается, будет ограничен только своей памятью. А если ему надо больше - то хрен тебе? :)

Если ему надо больше, то добычей данных занимается другой процессор.

Смысл такой, чтобы не ловить баги в планировщике ОС с NUMA - сама архитектура не настолько старая как SMP и могут иметь место недоработки в планировщике => падение производительности. Отключить ессно не вообще, а только на время теста.

Ты в этом уверен? :) Расскажи, например, как отключить на банальном proliant'е

1) Enter the DL585 ROM-Based Setup Utility by pressing F9 when prompted during the POST.
2) Select Advanced Options.
3) Select Enable Node Interleaving.

To enable NUMA, set Node Interleaving to Disabled - to disable NUMA, set Node Interleaving to Enabled.

VMWare рекомендует нуму включать, да и выводить хост из кластера для её отключения мне как-то лень :) В общем я думаю, что тема исчерпана, бинд - тормоз, но буду юзать его т.к. удобно. Нагрузок в 60к запросов у меня один фиг нет, ДДоСили разок, но по-детски, 2-3 тысячи в секунду, выдержим :) Да и перед биндом стоит ASA, которая спасёт ежели что.

это вопрос или утверждение?

vSphere никто не затачивал исключительно под винду
VC и VC client изначально были написаны под винду

гм. оксюморон налицо. IMHO у кого-то шизофрения ;-) лирика и многабукафф - пропущены IRL ты не развернёшь вэсфирь без наличия хотя бы 1 венды. ЧИТД.

консоли для гипервизоров ESX использовался RHEL

«преданья старины глубокой» - мы ж вродже про сегодня говорим, а то я могу ещё вспомнить как время переставляли системное и либу пачили для WS 1.0 ;-)

похоже на то :(

ну вариант ещё - попробовать пересобрать его с выбросом всякой ненужной муйни и strip'ом - мне в своё время это помогло уменьшить его аппетиты для запуска на маломощном железе.

гм. оксюморон налицо. IMHO у кого-то шизофрения ;-)

Не видишь разницу между «затачивался» и «изначально был написан»?

IRL ты не развернёшь вэсфирь без наличия хотя бы 1 венды.

И без хотя бы одного ESX/ESXi, ага? Кроме того, сейчас VC доступен в виде virtual appliance

Ну, у меня как раз самосбор, всё ненужное выкинуто, оптимизации (как выше я писал) дали снижение на 100% нагрузки ядер ЦП, но скорость осталась примерно там же.

значит доктор Бернштайн был таки прав :-)

Кроме того, сейчас VC доступен в виде virtual appliance

Которая требует 8ГБ памяти минимум насколько я слышал ;)

VC доступен в виде virtual appliance

ну, про 8Гб уже вроде сказали?8)

и да, я сразу вспомнил про барона МюнГаузена с его волосами и болотом. другими словами - то есть можно только так, через оппу?

и после этого мне будут говорить что новая вмварь не заточена под венду? и за 3 года не сделали даже никакого подобия VC client не под венду? не, в сад такой vendor lock-in!

Вам шашечки, или ехать? Вмварь - один из старейших гипервизоров и полноценная виртуальная среда. Которая успела обрасти многими дополнительными программами вроде бэкапов, средств автоматизации и т.п. Ну и все серьезные баги выпилили. А с KVM сотоварищи я пока связываться боюсь, через пару лет посмотрю что там как.

Я сам не особо доволен тем, что vsphere client только под винду, но это особо напрягает только задротов, а если вдуматься, то главное - то, как работает сама инфраструктура. А меня она за несколько лет, в общем, только радует.

напрягает только задротов

это типа наезд чоле?

все серьезные баги выпилили.

ню-ню, блажен кто верует.:-)

как работает сама инфраструктура

ну как бы тенденция есть (в первую очередь проверяется всё связанное с вендой). и это не радует и как бы намекает...

Ну, начиная с версии 4.1 я багов особых не встречал, это для меня главный показатель. А насчет винды, так это коньюнктура рынка такая, ничего не поделаешь. Но и с линупсами там тоже все хорошо. Сеть виртуальая та же вполне выдает 10гбит.

Тут еще вот что СОВЕРШЕННО СЛУЧАЙНО увидел:

# rndc status
...
query logging is ON
...

Хотя в конфиге стоит:

    category queries {
        null;
    };

Закомментил эту непонтребность, и скорость поднялась до 170к запросов в секунду на 6 vCPU. Вот так вот, слона-то я и не приметил... всегда считал что null - это выключено. Хрен там. Видать в /dev/null писало и тратило на это 60-70% времени.

Резюмирую: Бинд не такое уж и говно. Проц жрёт, конечно, как лось, но и скорость при этом достойная. Аминь.