The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

17.06.2015 20:45  Оценка способности сетевого стека Linux обрабатывать миллион пакетов в секунду

Марек Майковски (Marek Majkowski), разработчик ядра Linux, работающий в компании CloudFlare, провёл заслуживающий внимания эксперимент, пытаясь разобраться насколько быстр сетевой стек ядра Linux и возможно ли в Linux обеспечить работу пользовательского приложения, способного обработать миллион UDP-пакетов в секунду на обычном сервере с шестиядерным CPU Xeon (2GHz) и сетевой картой 10G.

В эксперименте применялась связка из программы для отправки данных, использующая вызов sendmmsg для отправки информации порциями по 1024 пакета за раз, и программы для приема данных, использующая системный вызов recvmmsg, более эффективный чем recv благодаря пакетной обработке данных.

Первый вариант приложения продемонстрировал производительность отправки данных в диапазоне от 197 до 350 тысяч пакетов в секунду. Непостоянство производительности объяснялось миграцией обработчиков между ядрами CPU. После жесткого закрепления программы за одним ядром CPU возросла эффективность кэша и производительность стабилизировалась на отметке в 350 тысяч пакетов в секунду. Следующим шагом стало распараллеливание отправки в несколько нитей, генерация пакетов значительно возросла, но принимающая программа не смогла обработать больше чем при первой попытке, уперевшись в производительность ядра CPU, выполняющего код приложения.

Данное ограничение удалось преодолеть при помощи задействования нескольких принимающих очередей (RX queue), привязанных к разным CPU и закреплённых за разными IP-адресами. Распределение запросов по двум принимающим очередям увеличил производительность до 650 тысяч пакетов в секунду. Попытка дальнейшего увеличения числа RX-очередей привела к очередному узкому месту - несмотря на то, что сетевая карта справлялась с доставкой пакетов ядру, ядро оказалось не способно доставить их приложению, которое не успевало их принимать. Увеличение числа принимающих нитей, из-за ограниченного размера буфера UDP, не улучшило положение.

Справиться с ограничением помог флаг SO_REUSEPORT, позволяющий сразу нескольким слушающим сокетам подключиться к одному порту для приёма соединений. При этом каждый обработчик использует отдельный дескриптор сокета, т.е. свой отдельный принимающий буфер UDP. Запустив четыре обработчика производительность удалось довести до 1.1 млн пакетов в секунду. Привязав обработку RX-очереди и принимающее приложение к одному узлу NUMA производительность удалось поднять до 1.4 млн пакетов в секунду.

  1. Главная ссылка к новости (https://blog.cloudflare.com/ho...)
Лицензия: CC-BY
Тип: Практикум
Ключевые слова: linux, kernel, speed
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 21:20, 17/06/2015 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    udp/udp-lite прост, лучше бы провели тесты TCP...
     
     
  • 2.13, Pilat (ok), 05:07, 18/06/2015 [^] [ответить]    [к модератору]
  • +8 +/
    > udp/udp-lite прост, лучше бы провели тесты TCP...

    С подтверждением ? Это будет тест чего?

     
  • 1.2, A.Stahl (ok), 21:20, 17/06/2015 [ответить] [показать ветку] [···]    [к модератору]
  • +7 +/
    Пакеты, надо полагать, пустые?
    С одной стороны это очень много и круто, но любопытно было бы сравнить с кем-то.
    Что скажут BSDшники, которые всегда указывают на свой сетевой стек, когда заходит речь о полезности их системы. Может для BSD это вообще не масштаб?
     
     
  • 2.3, Аноним (-), 21:40, 17/06/2015 [^] [ответить]    [к модератору]
  • +/
    Спроси у Netflix и NGinx (они контрибутят ядро BSD), линукс на свой страх и риск.
     
     
  • 3.32, Аноним (-), 19:53, 18/06/2015 [^] [ответить]    [к модератору]
  • +/
    > Спроси у Netflix и NGinx (они контрибутят ядро BSD), линукс на свой страх и риск.

    Так мы и спрашиваем: покажете 1М+ PPS на обычной машине? Отмазы про нжинкс и нетфликс - не есть циферки в бенчах.

     
     
  • 4.47, bOOster (ok), 03:37, 22/06/2015 [^] [ответить]     [к модератору]  
  • –1 +/
    С бумажкой на которых напечатаны эти циферки в бенче - можешь в толчок сходить и... весь текст скрыт [показать]
     
  • 4.48, Аноним (-), 18:34, 15/08/2015 [^] [ответить]    [к модератору]  
  • +/
    >покажете 1М+ PPS на обычной машине?

    Обычная такая машина с 10G и NUMA :) Попей уже водички ..

    PS: Нововсти этой месяца 3 уже как, с разморозкой ! :)

     
  • 2.4, Аноним (-), 21:48, 17/06/2015 [^] [ответить]    [к модератору]  
  • +/
    http://wand.net.nz/pubs/211/pdf/p21.pdf
     
     
  • 3.5, A.Stahl (ok), 21:55, 17/06/2015 [^] [ответить]     [к модератору]  
  • +5 +/
    Ну этот документ стар и считает не пакеты, а килободы И TCP, а не UDP Впрочем,... весь текст скрыт [показать]
     
     
  • 4.6, oopss (?), 22:01, 17/06/2015 [^] [ответить]    [к модератору]  
  • +3 +/
    Бугога) Верни мне мой 2007й?
     
     
  • 5.7, Crazy Alex (ok), 22:05, 17/06/2015 [^] [ответить]    [к модератору]  
  • +6 +/
    Нет проблем, тащите свежие данные
     
     
  • 6.17, oopss (?), 08:24, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    да данные такой давности даже упоминать глупо
     
  • 4.8, Sadok (ok), 22:09, 17/06/2015 [^] [ответить]     [к модератору]  
  • +2 +/
    Поперхнулся 5 х, помнится, даже в продакшене нигде не жила С 4 сразу на 6 прыг... весь текст скрыт [показать]
     
     
  • 5.9, Аноним (-), 22:15, 17/06/2015 [^] [ответить]     [к модератору]  
  • +/
    Про производительность Multipath TCP for FreeBSD на 10GbE коробке тоже не слова ... весь текст скрыт [показать]
     
     
  • 6.10, Аноним (-), 22:16, 17/06/2015 [^] [ответить]     [к модератору]  
  • +/
    100G... весь текст скрыт [показать]
     
     
  • 7.33, Аноним (-), 19:55, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    >> Про производительность Multipath TCP for FreeBSD на 10GbE коробке тоже не слова...
    > 100G

    Угу, покажи нам миллионы PPSов и 100Гбит.

     
  • 5.18, XoRe (ok), 09:07, 18/06/2015 [^] [ответить]     [к модератору]  
  • +/
    Кое-где попала и в продакшен, кровь попортила изрядно Не только переходом на SM... весь текст скрыт [показать]
     
  • 4.21, t28 (?), 09:38, 18/06/2015 [^] [ответить]     [к модератору]  
  • +1 +/
    Боды 8212 это вообще о чём вы Вообще-то Бод 8212 это единица измерения ... весь текст скрыт [показать]
     
     
  • 5.22, A.Stahl (ok), 09:50, 18/06/2015 [^] [ответить]    [к модератору]  
  • –1 +/
    Не ной. Да, некорректно использовал термин. Но идея ясна.
     
  • 4.46, Аноним (-), 02:23, 22/06/2015 [^] [ответить]    [к модератору]  
  • +/
    Вы бы внимательно перечитали документ, а конкретно размеры буфера и TCP-окна в Windows XP SP2. Что за замеры такие, когда тесты проводятся с параметрами по умолчанию?!
     
  • 2.11, iZEN (ok), 23:10, 17/06/2015 [^] [ответить]    [к модератору]  
  • –5 +/
    Можно здесь посмотреть некоторые соображения: https://calomel.org/network_performance.html
     
     
  • 3.19, Andrey Mitrofanov (?), 09:18, 18/06/2015 [^] [ответить]     [к модератору]  
  • +/
    Соединение с calomel org было неожиданно прервано Возможно, также была прерва... весь текст скрыт [показать]
     
     
  • 4.25, Аноним (-), 11:36, 18/06/2015 [^] [ответить]    [к модератору]  
  • +1 +/
    > ""Соединение с calomel.org было неожиданно прервано. Возможно, также была прервана передача
    > данных.""
    > Посмотрел. В ахе.

    Вот как-то так оно пакеты и обрабатывает.

     
     
  • 5.28, Аноним (-), 13:21, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    h2o и http/2.0 вас приветствует...

    говорят у h2o 20% запросов это отказ

     
  • 3.34, Аноним (-), 20:06, 18/06/2015 [^] [ответить]     [к модератору]  
  • +2 +/
    Самое годное что там есть - фоновая картинка Которая однако прозрачно намекает ... весь текст скрыт [показать]
     
     
  • 4.44, Аноним (-), 12:28, 19/06/2015 [^] [ответить]     [к модератору]  
  • +/
    Ух ты Так там, внезапно, вдруг, оказывается, b исследуется b производительно... весь текст скрыт [показать]
     
  • 3.38, AlexAT (ok), 22:02, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    А теперь в юзерспейсе.


     
  • 2.20, t28 (?), 09:33, 18/06/2015 [^] [ответить]     [к модератору]  
  • –5 +/
    350 kpps 8212 это мало и совсем не круто Уровень 1 Mpps достижим при отказе ... весь текст скрыт [показать]
     
     
  • 3.26, Аноним (-), 11:46, 18/06/2015 [^] [ответить]    [к модератору]  
  • +1 +/
    Это конечно же полный бред.
     
  • 3.35, Аноним (-), 20:08, 18/06/2015 [^] [ответить]     [к модератору]  
  • +/
    Вообще-то для х86 самого по себе - без дополнительых ухищрений очень сложно дерн... весь текст скрыт [показать]
     
     
  • 4.37, AlexAT (ok), 22:01, 18/06/2015 [^] [ответить]    [к модератору]  
  • +1 +/
    Ну сетевухи уже давно не дёргают x86 на каждый пакет, тащемта.
     
     
  • 5.39, Аноним (-), 01:49, 19/06/2015 [^] [ответить]    [к модератору]  
  • –1 +/
    > Ну сетевухи уже давно не дёргают x86 на каждый пакет, тaщeмта.

    Ну да. Там всякие довольно жестокие изгаления по части interrupt mitigation, насколько я знаю.

     
  • 2.23, Dmitry (??), 10:13, 18/06/2015 [^] [ответить]    [к модератору]  
  • –3 +/
    Миллион восемьсот пакетов в секунду при включенном fastforwarding

    http://bsdrp.net/documentation/technical_docs/performance

     
     
  • 3.24, Аноним (-), 11:34, 18/06/2015 [^] [ответить]    [к модератору]  
  • +2 +/
    Cкажите мне как художник художнику, вы читать умеете ?
     
     
  • 4.40, Аноним (-), 05:41, 19/06/2015 [^] [ответить]    [к модератору]  
  • –2 +/
    Если в тексте написано что BSD как обычно вздрючило пингвина, и _подробно_ расписано как повторить опыт ... то для художников оно не читаемо? Ню-ню :)
     
     
  • 5.45, Аноним (-), 12:38, 19/06/2015 [^] [ответить]     [к модератору]  
  • –1 +/
    Ну, вы ведь понимаете, что именно ЭТОТ конь -- абсолютно неправильной сферичност... весь текст скрыт [показать]
     
  • 3.36, Аноним (-), 20:10, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    > Миллион восемьсот пакетов в секунду при включенном fastforwarding

    Круто. А теперь попробуй получить 1.8М пакетов в секунду программой в юзерспейсе и расскажи как получилось.

     
     
  • 4.43, Dmitry (??), 11:01, 19/06/2015 [^] [ответить]    [к модератору]  
  • +/
    >> Миллион восемьсот пакетов в секунду при включенном fastforwarding
    > Круто. А теперь попробуй получить 1.8М пакетов в секунду программой в юзерспейсе
    > и расскажи как получилось.

    Про netmap прямо здесь рассказывать ?

     
  • 1.14, svsd_val (ok), 05:57, 18/06/2015 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Весьма и весьма не плохо, интересно аналогичные результаты можно достичь на мелко мягких ?
     
  • 1.16, Аноним (-), 08:13, 18/06/2015 [ответить] [показать ветку] [···]     [к модератору]  
  • –4 +/
    тут больше в само ядро упирается чем в трюки вокруг него помнится, N2O, Yaws... весь текст скрыт [показать]
     
     
  • 2.27, Аноним (-), 11:46, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    Очередное творчество душевнобольных.
     
  • 2.29, YetAnotherOnanym (ok), 14:13, 18/06/2015 [^] [ответить]    [к модератору]  
  • +1 +/
    А что, Erlang на QNX уже считается пригодным для эксплуатации? Сами создатели эрланга на вопрос о работе под QNX отвечают "Там какой-то чувак пилит порт, спроси в рассылке".
     
  • 2.30, fleonis (?), 14:39, 18/06/2015 [^] [ответить]    [к модератору]  
  • +/
    что за тесты? есть ссылка?
     
  • 2.41, Аноним (-), 05:44, 19/06/2015 [^] [ответить]    [к модератору]  
  • +1 +/
    > выдавали  QNX до в 30х и 8х раз больший траффик с того-же железа.

    Сказочник грёбанный :))))
    QNX - редкий тормоз в сетях, это я тебе как доктор говорю :)

     
  • 1.31, rob pike (?), 14:46, 18/06/2015 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Разбор полётов внутри ядра - где тормоза и куда пилить - https://lwn.net/Articles/629155/, http://people.netfilter.org/hawk/presentations/LCA2015/net_stack_challenges_1
     
  • 1.42, ArtemDPI (?), 10:46, 19/06/2015 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    1M пакетов для 10G - это, всё же, мало.
    Физический предел для такого интерфейса - около 15M фреймов в секунду (с минимальной полезной нагрузкой 64Б) и около 5M фреймов со средним размером полезной нагрузки в 256Б (сегодня в сетях примерно так). Учитывая, что интерфейсы дуплексные, умножаем на 2.
    Соответственно, если мы хотим хотя бы близко подойти к использованию всех возможностей 10G интерфейса (про 40 и 100 молчу), сетевой стек Linux использовать нельзя.
    Для этого и пилят всякие DPDK и Netmap'ы (там мы, правда, начинаем уже упираться в память, процессоры и интерконнект, но это уже другой вопрос).
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor