Тюнинг FreeBSD 8.2. Часть 2. Производительность.

[dadv]

В продолжение темы.

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

Производительность роутера обсуждается в контексте трафика в сотни мегабит или единиц гигабит в секунду (не 10G).

• Не экономьте на хороших сетевых платах. Наилучшие из использованных мной плат для витой пары это платы на чипе Intel 82576 (драйвер igb) - они меньше всего нагружают процессор прерываниями плюс могут помогать операционной системе выравнивать загрузку ядер CPU, генерируя не одно, а несколько прерываний на материнских платах, поддерживающих технологию MSI-X (на материнских платах тоже не экономьте), таким образом, позволяя ОС обрабатывать входящий трафик с одной карты параллельно несколькими ядрами.
  
  Интегрированные карты на основе Intel 82574L показали себя хуже (больше грузят процессор прерываниями), но в итоге сгодились и они.
  
  Гигабитные сетевые карты Realtek, несмотря на зачаточный interrupt moderation и его поддержку драйвером re, показали полную негодность на современном Internet-трафике, где средний размер пакета - порядка 600 байт. Слишком сильно грузят процессор прерываниями, при этом неспособны справляться с соответствующим количеством пакетов в секунду (pps).
  
  
• Кстати, о pps (пункт только для владельцев сетевых карт Intel). По умолчанию, драйвера em и igb программируют чипы генерировать не более чем 8000 прерываний в секунду, опасаясь перегрузить CPU прерываниями. 8000 это очень мало для современных процессоров, и, если не принять мер, процессор останется недогружен, а пакеты при этом будут застаиваться в буферах карты и дополнительные задержки будут расти до сотен или даже тысяч милисекунд на пустом месте.
  
  В нынешней 8.2-STABLE драйвер igb поддерживает loader tunnable hw.igb.max_interrupt_rate с дефолтом 8000, позволяющий изменить этот дефолт. Драйвер em ничего такого не поддерживает. Оба драйвера не поддерживают изменения параметра через sysctl (без перезагрузки).
  
  Патчи для em и для igb исправляют эту ситуацию: у em появляется поддержка аналогичного loader tunnable hw.em.max_interrupt_rate и у обоих поддержка sysctl dev.em.X.max_interrupt_rate (аналогично для igb), для которых loader tunnables задают значения по умолчанию. Патч сыроват в том смысле, что изменение sysctl не вступает в силу сразу, для этого нужно каким-то образом инициировать перепрограммирование чипа - например, это можно сделать через ifconfig down/up. При указании нужных значений в loader.conf этой проблемы нет, значения прописываются в чип при первом поднятии интерфейса. Для достижения цифр, указанных в более раннем посте, пришлось выставлять 32000 и для em, и для igb (16000 оказалось тоже мало).
  
  Update 1.03.2012: обновление патчей для 8.3-PRERELEASE: em и igb. Работают и на 9.1.
  
  Update 7.10.2013: обновление патча на em для 9.2-RELEASE: em. Патч для igb всё ещё годится старый, от 8.3 (выше).
  
  Update 9.10.2014: обновление патча на igb для 9.3: igb.
  
  Update 29.01.2015: обновление патча на igb для 9.3-STABLE: igb.
  
  Update 14.02.2015: обновление патча на em для 9.3-STABLE: em.
  
  Update 16.11.2015: патч для драйвера старых сетевых гигабиток Intel для 9.3-STABLE: lem; обновление патча на em для 10.2: em; обновление патча на igb для 10.2: igb.
  
  Update 7.09.2016: обновление патчей для 11.0: lem, em, igb.
  
  Патчи эти не отменяют использования штатного interrupt moderation, поддерживаемого всеми гигабитными чипами карт Intel. Для понимания этой технологии и указанных ниже sysctl совершенно необходимо прочитать и понять первоисточник: http://download.intel.com/design/network/applnots/ap450.pdf (или аналогичную документацию).
  
  В /boot/loader.conf пишем:
  
  hw.em.rxd=4096
hw.em.txd=4096
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.max_interrupt_rate=32000
hw.em.max_interrupt_rate=32000
  
  В /etc/sysctl.conf:
  
  dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096

dev.em.1.rx_int_delay=200
dev.em.1.tx_int_delay=200
dev.em.1.rx_abs_int_delay=4000
dev.em.1.tx_abs_int_delay=4000
dev.em.1.rx_processing_limit=4096

dev.igb.0.rx_processing_limit=4096
dev.igb.1.rx_processing_limit=4096
  
  
• Дополнительный тюнинг NETGRAPH.
  
  В /etc/sysctl.conf также полезно увеличить и другие буферы для стабильной работы утилиты ngctl:
  
  net.graph.maxdgram=8388608
net.graph.recvspace=8388608
  
  
• Там же имеет смысл поднять длины некоторых других очередей, связанных с обработкой пакетов различными ядерными сетевыми подсистемами во избежание переполнения этих очередей:
  
  # for rtsock
net.route.netisr_maxqlen=4096
  
  

  В /boot/loader.conf:

  # for other protocols (IP & PPPoE?)
net.isr.defaultqlimit=4096

# default outgoing interface queue length
# used by lagg etc.
net.link.ifqmaxlen=10240
  
  Через /etc/sysctl.conf отдаём порядка гигабайта ядерной памяти на сетевые буфера, так как нынешняя FreeBSD 8.2 может войти в "клинч" (не падает, но и не обслуживает абонентов) при их переполнении и не выйти из него самостоятельно.
  
  kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080

  

• Для использующих dummynet с высокими скоростями: в /etc/sysctl.conf имеет смысл увеличить максимально допустимую длину очереди шейпера и включить режим io_fast, уменьшающий задержки и разгружающий CPU за счет пропуска без шейпинга пакетов тех пользователей, которые не выбирают своей полосы:
  
  net.inet.ip.dummynet.pipe_slot_limit=1000
net.inet.ip.dummynet.io_fast=1
  
  
• Прочий тюнинг /etc/sysctl.conf:
  
  net.inet.ip.fastforwarding=1
# на тот случай, если работу netisr стабилизируют в будущем, увеличиваем длину очереди под входящие пакеты:
net.inet.ip.intr_queue_maxlen=10240

• Использование lagg.
  
  Если трафик через роутер хотя бы в одну сторону приближается с гигабиту при использовании карт 1G, один из вариантов (кроме перехода на 10G :-) это использование lagg (etherchannel, portchannel, trunking, bonding - есть много терминов для одного и того же по сути).
  
  lagg в 8.2 годится к использованию, но и тут прячутся грабли (update 1.03.2012: описанная в этом пункте проблема исправлена, начиная с 8.3-PRERELEASE и 9.0-STABLE). Начиная с версии 8.0, драйвер lagg научился обращать внимание на тег M_FLOWID, который драйвер сетевой карты, первоначально принявшей пакет, мог навесить на буфер, содержащий этот пакет. Такие теги на пакет могут навешивать драйвера сетевых карт, поддерживающие MSI-X и использующие больше одного вектора прерывания для информирования ядра о приёме данных. В метаданных такого пакета хранится "номер потока", аппаратно сгенерированный принявшей пакет сетевой картой и донесенный до сведения операционной системы посредством генерации прерывания с нужным номером.
  
  Например, карта на чипе 82576, на материнской плате с поддержкой MSI-X и четырьмя ядрами CPU может использовать четыре вектора прерываний, и драйвер igb в зависимости от того, посредством какого прерывания пришел пакет, приклеивает пакету один из четырех "номеров потока".
  
  Увидев такой пакет, драйвер lagg при выборе исходящего порта для пакета пропускает вычисление хеша для него (для экономии тактов CPU) и выбирает порт, используя остаток от деления номера потока на количество портов исходящего интерфейса. В теории всё прекрасно, но...
  • Смотрим datasheet на карту: http://download.intel.com/design/network/datashts/82576_Datasheet.pdf
    Для распределения пакетов по очередям карта использует спецификацию Microsoft Receive-Side Scaling (RSS) и даташит ссылается на неё на странице 274, упоминая реализованную хеш-функцию, которая реализована в чипе аппаратно и результат которой определяет, какой вектор прерывания будет использован для пакета.
    
  • Смотрим спецификацию RSS от Microsoft: http://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf0072878e6/ndis_rss.doc
    На странице 7 спецификации сказано, от чего может считаться хеш: от IP-адресов (IPv4 или IPv6) и, опционально, портов TCP (но не UDP). Номера тегов 802.1q не используются. На странице 9 сказано, что если пакет не имеет указанных параметров, от которых брать хеш, то он не хешируется.
    
  • На практике это означает, что все фреймы PPPoE/GRE, приходящие через пучок vlan-ов и карты igb, попадают в одну "очередь" внутри карты и обслуживаются одним вектором прерываний и никакого распределения нагрузки по ядрам не получается.
    
  • Как следствие, драйвер igb назначает им всем одинаковый (нулевой) "номер потока".

  В итоге, драйвер lagg все такие пакеты посылает только в один из своих портов и нет также никакой балансировки нагрузки по сетевым картам на выход в сторону аплинка.
  
  Патч на lagg вводит новый sysctl net.link.lagg.use_flows с дефолтным значением 1. Изменив его на 0, получим старое поведение времен FreeBSD 7.x, когда lagg всегда самостоятельно вычисляет хеш от пакета. И получим восстановленное балансирование исходящего трафика по портам lagg.
  
  Этот патч тоже сыроват в том смысле, что вводит глобальный sysctl, хотя можно было бы ввести по одному sysctl для каждого lagg и немного сэкономить CPU за счет использования "хороших" номеров потоков, сгенерированных теми сетевыми картами, которые получают трафик не в виде фреймов PPPoE, а в виде простых пакетов IPoE. Пока руки не дошли переделать патч. См. тут.
  
  Ну и ещё мелкая проблема в lagg: он неправильно считает статистику unicast/non-unicast pps, поэтому при рисовании графика pps с интерфейсов lagg получаем нули для non-unicast. Эта же статистика по индивидуальным портам отдаётся драйверами em/igb корректно. Тоже не доходят руки поправить.
  

Продолжение следует.

Comments

[blacklion.livejournal.com]

А что скажешь про 82575EB? У нас на нём потери пакетов (UDP) при ~600-800Mbit/s входящего трафика пакетами по ~1000 байт. Тут Solaris, буфера увеличили до максимума (аналог фряхиного rxd/txd), но от потерь полностью не избавились, только снизили.

[dadv.livejournal.com]

Про солярку ничего не скажу. Возможно, там есть буфер для входящих пакетов типа netisr на фре? Надо его найти, и если найдется, увеличить :-)

Буфер не в сетевой карте, а в ядре.

[doctornkz.livejournal.com]

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

[dadv.livejournal.com]

Забыл, ага. Поправил. Ваши все это знают наверняка.

[blacklion.livejournal.com]

Это всё наши админы крутить умеют и укрутили на масимум. Жалуются, что в статистике карты есть строчка по смыслу “не смогли принять так как не смогли захватить буфер” и она вот растёт :(

[dadv.livejournal.com]

Похоже на то, что ОС слишком редко/медленно выбирает эти буфера из карты? CPU случаем не перегружен? Если нет, надо обратить внимание на те самые прерывания, генерируемые картой и посмотреть, а не ограничены ли они какой константой, как во фре?

[blacklion.livejournal.com]

Похоже на то. CPU загружен умеренно, суммарно не больше 25%. Про параметр максимальной частоты прерываний я им сказал, ищут, но там в солярке какие-то совсем другие настройки и совсем другая версия драйвера и вообще вроде и (c) Intel как и во фряхе, но всё другое на вид.

[blacklion.livejournal.com]

О! Вот ещё вопрос -- что кроме man ipfw читать про новый dummynet? Все мурзилки про старый, а новый разобран в мане плохо -- например, я так и не понял, является ли pipe синонимом для sched type fifo или нет, и всегда ли нужны все три компонента и размножается ли pipe когда размножается sched.

[dadv.livejournal.com]

Я с новым обращаюсь ровно так же, как со старым. То есть, не изучал ещё отличия. Работает не трогай :-)

[fuflolog.livejournal.com]

Голь на выдумки хитра!

[freetiger.livejournal.com]

а intel 82573 ведет себя так же, как 82574?

[blacklion.livejournal.com]

Интересно, почему это так зачастую воспринимается?

[blacklion.livejournal.com]

И про старый-то хорошей документации мало :(

[fuflolog.livejournal.com]

Потому что если некто делает довольно неочевидные вещи, пытаясь сэкономить конторе деньги, это обычно означает, что его собственная зарплата мала по сравнению со стоимостью оборудования.

[blacklion.livejournal.com]

А то, что результат может быть не только дешевле, но и УДОБНЕЕ или что нет оборудования, на 100% подходящего и любое будет компромиссом, а вот такое решение — наименьшим компромиссом, это невозможно, да?

[blacklion.livejournal.com]

Просто — смотри выше — у нас вот на работе не экономят на оборудовании, покупают брендовое железо с брендовой OS, и контрактом на поддержку. И что, нас это спасает? Да нифига. Пакеты теряются, техподдержка за многобабла разводит руками и советует докупить ещё один сервер и не париться (а то, что ещё один сервер — это НЕ ТОЛЬКО деньги, это никого не волнует, конечно). Уж лучше бы сами на FreeBSD собирали — его хоть можно пропатчить если что.

[blacklion.livejournal.com]

Просто мне эта позиция очень напоминает веру в серебряную пулю. Как будто боги горшки обжигают и оборудование брендов — это что-то созданное небожителями, ага.

[fuflolog.livejournal.com]

Человек, способный собрать аналог сиски, должен получать сравнимо с сиской, разве нет?

Покупая сиску, мы много тратим на железо вначале, но потом сажаем дешевого мальчика, который умеет логи смотреть и кейсы в ТАС открывать.

Покупая дешевые сервера, мы мало тратим в начале, но много платим на содержание в штате юниксоида на все время жизни решения (см. пункт 1). Что, домик юниксоида не светится богатством и огнями? Ну так и я о том же - юниксоиду не доплачивают.

[blacklion.livejournal.com]

И какое отношение это имеет к “голь на выдумки хитра”?

И откуда мы знаем, что топикстартеру недоплачивают? :)

[fuflolog.livejournal.com]

Ну я уже все разжевал и в рот положил, дальше ты уж сам как-нибудь.

[blacklion.livejournal.com]

Что “как-нибудь”? Мы вроде пришли к выводу, что использование не-циско — это не только от нежелания платить денег Циско может быть и голь тут не при чём.
А уж зарплаты специалистов — это второй вопрос.

[dadv.livejournal.com]

Судя по RTFS, у 82573 только 32000 буферов буферов под пакеты против 40000 у 82574. Кроме того, у 82573 есть некоторые проблемы с latency на части систем. Плюс у 82573L размер JumboFrames ограничен 9238 байтами против 16128 у 82574, а 82573V/E вообще не поддерживают JumboFrames.

На практике я их не сравнивал.

[freetiger.livejournal.com]

разжевали, ткнули носом в документацию, спасибо.

[orao.livejournal.com]

Дурацкий вопрос, почему именно FreeBSD, а не центось например, для подобных BRAS - задач?

[orao.livejournal.com]

Обычно всё не так.
Во-1, производительность Unix-серверов сравнима с производительностью железа начального уровня.
Пока о Nx10G софтверных рутерах речь почти не идёт. И BRAS на Unix обычно делается в качестве альтернативы 7206VXR/NPE-G2, а никак не ASR9000.
На этом этапе разницы между Unix и Cisco по производительности может не быть, она может быть не в пользу Cisco, и т.д..
Но очень часто Cisco вкуснее с коммерческой-организационной точек зрения.
В конце концов, если упала сеть, построенная на оборудовании производства лидера рынка, на котором построены сети таких гигантов, как ... , отчитаться перед инвесторами легче, чем если упала сеть, построенная на самопальных решениях, даже если последняя упала менее болезненно.