Comments 15
Ребята и девчата, а можно все-таки хоть немного подробностей про самописный DNS-сервер? За счет чего такая производительность, более-менее подробные условия и результаты perfomance-тестов?
Цифра 3M qps, да еще и на ядро (подразумевается же, что она масштабируется при росте количества ядер линейно или близко к этому?) — очень серьезно для того, чтобы поверить на слово. Knot, pdns и остальные дают в лучшем случае сотни тысяч qps, и не на одном ядре.
И да, в тред призывается Александр flx Лямин, который в прошлом году на PhD рассказывал про ~15M pps на 16 (если не путаю) ядрах как про серьезное достижение. А тут получается минимум 6M pps (если сложить входящий и исходящий), да еще на одно ядро, да еще и с обработкой в user space. За год многое поменялось и теперь другие ориентиры?
Цифра 3M qps, да еще и на ядро (подразумевается же, что она масштабируется при росте количества ядер линейно или близко к этому?) — очень серьезно для того, чтобы поверить на слово. Knot, pdns и остальные дают в лучшем случае сотни тысяч qps, и не на одном ядре.
И да, в тред призывается Александр flx Лямин, который в прошлом году на PhD рассказывал про ~15M pps на 16 (если не путаю) ядрах как про серьезное достижение. А тут получается минимум 6M pps (если сложить входящий и исходящий), да еще на одно ядро, да еще и с обработкой в user space. За год многое поменялось и теперь другие ориентиры?
Привет.
Интересная статья, и спасибо за хотлинк в почту ;)
3M qps звучит действительно внушительно. Отличный результат сравнимый со скорострельностью современных пакетных генераторов.
Несколько не вяжется с выбранным хранилищем — memcached.
3Mqps на ядро, это надо полагать пиковая производительность для вырожденного случая, когда все ответы попадают в кэш процессора?
С удовольствием побенчмаркаем ваше решение ;)
Интересная статья, и спасибо за хотлинк в почту ;)
3M qps звучит действительно внушительно. Отличный результат сравнимый со скорострельностью современных пакетных генераторов.
Несколько не вяжется с выбранным хранилищем — memcached.
3Mqps на ядро, это надо полагать пиковая производительность для вырожденного случая, когда все ответы попадают в кэш процессора?
С удовольствием побенчмаркаем ваше решение ;)
Немного подробностей конечно же можно. Это были синтетические замеры на отдачу А записей без участия сетевого стека, то есть при условии включения сюда работы драйвера сетевой — qps уже значительно падает. Но — смотря какой сетевой карты, продукт писался не как user-space именно по причине работы на кластере в среде infiniband — и пришлось немного подпиливать rdma
В случае дополнительных вычислений вроде проверки acl при отдаче AXFR запроса результаты тоже значительно падают (два чтения из памяти) — до 2.5-3 раз. Даже была мысль в реализации «сложных» запросов (AXFR, рекурсивных, DNSSEC с проверкой подписи) в отдельном модуле, но не сложилось — поэтому просто не реализовывали рекурсию и сделали только костыльный AXFR смирившись с необходимостью.
По поводу производительности — она растет нелинейно, в первую очередь это связано с тем что при увеличении количества процессоров/ядер увеличивается нагрузка на ht/qpi на не-numa системах (а их большинство к сожалению в нашем парке), в случае numa доступа к памяти — падение уже не такое значительное. Это касается только синтетических тестов. 3М запросов — 1.4 гбита — это совершенно небольшая цифра, непонятно чем она так удивляет. Для того чтобы была небольшая ясность — opteron 250 прогоняет «по даташиту» до 6 ГБ/с — на практике эта цифра на двухпроцессорной системе падает до 3 ГБ/с на чтение и 1.6 ГБ/с на запись, при лейтенси доступа к «своей» памяти около 40 нс и к «чужой» порядка 70 нс (разницы по скорости своя/чужая нету, только по времени доступа).
Когда мы спускаемся уже на уровень медиасреды — вот тут пожалуй самая большая загвоздка в производительности, и пока что бороться приходится именно с ней — тут уже вступают в силу другие факторы, как то: старенькие 6500 каталисты можно завалить 3.6 mpps мелкими пакетами — она просто умирает, при этом это даже не 100 мбит траффика.
fix: когда все ответы попадают в кеш процессора думаю что можно достичь максимума по тактам — но мне кажется что это фантастика ))
касаемо memcached — мы его выбрали как быстрый костыль вместо read+write модулей ядра под rdma, потому что своей инфраструктуры аналогичной заказчику — у нас просто нету, и надо было заюзать «что-то» под tcp стек, и для фришного сервиса решили — почему нет, мы все равно упираемся в сеть в результате
вобщем нету погони за «циферками», да и сервера на которых размещен сервис сейчас виртуальные (что добавляет очень неслабо к лейтенси). Цель паблик проекта — получить живой стресстест, ну и ловить баги потихоньку. Но будем рады тестам (особенно например скорости репликации — на данный момент по идее она лучше чем у всех паблик сервисов, ну может кроме гугла — не знаем как его замерить :-)
В случае дополнительных вычислений вроде проверки acl при отдаче AXFR запроса результаты тоже значительно падают (два чтения из памяти) — до 2.5-3 раз. Даже была мысль в реализации «сложных» запросов (AXFR, рекурсивных, DNSSEC с проверкой подписи) в отдельном модуле, но не сложилось — поэтому просто не реализовывали рекурсию и сделали только костыльный AXFR смирившись с необходимостью.
По поводу производительности — она растет нелинейно, в первую очередь это связано с тем что при увеличении количества процессоров/ядер увеличивается нагрузка на ht/qpi на не-numa системах (а их большинство к сожалению в нашем парке), в случае numa доступа к памяти — падение уже не такое значительное. Это касается только синтетических тестов. 3М запросов — 1.4 гбита — это совершенно небольшая цифра, непонятно чем она так удивляет. Для того чтобы была небольшая ясность — opteron 250 прогоняет «по даташиту» до 6 ГБ/с — на практике эта цифра на двухпроцессорной системе падает до 3 ГБ/с на чтение и 1.6 ГБ/с на запись, при лейтенси доступа к «своей» памяти около 40 нс и к «чужой» порядка 70 нс (разницы по скорости своя/чужая нету, только по времени доступа).
Когда мы спускаемся уже на уровень медиасреды — вот тут пожалуй самая большая загвоздка в производительности, и пока что бороться приходится именно с ней — тут уже вступают в силу другие факторы, как то: старенькие 6500 каталисты можно завалить 3.6 mpps мелкими пакетами — она просто умирает, при этом это даже не 100 мбит траффика.
fix: когда все ответы попадают в кеш процессора думаю что можно достичь максимума по тактам — но мне кажется что это фантастика ))
касаемо memcached — мы его выбрали как быстрый костыль вместо read+write модулей ядра под rdma, потому что своей инфраструктуры аналогичной заказчику — у нас просто нету, и надо было заюзать «что-то» под tcp стек, и для фришного сервиса решили — почему нет, мы все равно упираемся в сеть в результате
вобщем нету погони за «циферками», да и сервера на которых размещен сервис сейчас виртуальные (что добавляет очень неслабо к лейтенси). Цель паблик проекта — получить живой стресстест, ну и ловить баги потихоньку. Но будем рады тестам (особенно например скорости репликации — на данный момент по идее она лучше чем у всех паблик сервисов, ну может кроме гугла — не знаем как его замерить :-)
p.s. уже реализована запись статистики запросов, но пока это просто бинарная структура в памяти, постараемся все таки вывести ее в виде графиков на морду в ближайшее время
вопрос к знатокам: что бы вы выбрали для хранения аггрегированной статистики — rrd (минимально по месту) или mongo (максимально удобно)?
вопрос к знатокам: что бы вы выбрали для хранения аггрегированной статистики — rrd (минимально по месту) или mongo (максимально удобно)?
на многоядерных системах падение скорострельности еще во многом из-за увеличеных накладных на MESIF и синхронизацию кэша. вы просто посчитайте сколько атомарных инкрементов в секунду у вас набьется на Nehalem/Sandy/Haswell соответственно. Сильно удивитесь.
Ну и да, если бенчмарки по Knot на уровне 500kRPS про которые вы пишете вы брали из нас, то неплохо-бы было изучить датасет на котором мы это получили. Обмерять сферического коня в вакууме мы не стали…
Ну и да, если бенчмарки по Knot на уровне 500kRPS про которые вы пишете вы брали из нас, то неплохо-бы было изучить датасет на котором мы это получили. Обмерять сферического коня в вакууме мы не стали…
Есть производительные open source dns сервера например YADIFA, насколько Ваше решение производительней?
Мы год назад потестировали все opensource
выкладки можно посмотреть тут
www.slideshare.net/andreyleskin14/highload2013dns032
выкладки можно посмотреть тут
www.slideshare.net/andreyleskin14/highload2013dns032
не сравнивали, да и не публичный продукт делали, для нашего конкретного случая — по другому просто ее не решить было )
решали локальную проблему, по дороге решили сделать маленькую экосистему, вроде получилось — и в таком духе и думаем продолжать развивать
в данном случае производительность — это наша экономия на инфраструктуре для сервиса, что конкурентное преимущество перед аналогами :-)
решали локальную проблему, по дороге решили сделать маленькую экосистему, вроде получилось — и в таком духе и думаем продолжать развивать
в данном случае производительность — это наша экономия на инфраструктуре для сервиса, что конкурентное преимущество перед аналогами :-)
Самописный DNS сервер(C++)You made my day!
MemcachedTwice :)
Я к тому, что никто не знает, сколько дыр в вашем DNS сервере, даже вы, пока он не станет объектом атак.
А нужна ли вам такая бешеная производительность в начале проекта?
Вам бы этот продукт предложить за деньги dns хостерам, у которых уже есть большая нагрузка.
Sign up to leave a comment.
System-NS изнутри