Потери на сетевых картах, задержки в обработке и как с ними бороться

Версия 20 oleg
на мар 11, 2016 18:32.
<< Изменения с 19 по 20
по сравнению с
Текущая Отдел разработки Carbon Reductor DPI X
на июл 17, 2019 15:39.
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (90)

просмотр истории страницы
{toc}

В производительность модуля фильтрация не упирается, как правило единственной проблемой при запуске бывает не совсем корректное работающее по умолчанию оборудование (процессор, сетевые карты). Мы много сталкивались с этим, поэтому готовы помочь с настройкой этого оборудования для обеспечения отличной производительности.

Есть четыре вещи которые в основном влияют на потерю пакетов при приёме (допустим, нас не волнует как долго он будет проходить через нашу систему, то есть latency мы можем жертвовать), а наша задача - поймать все пакеты, не упустив ни одного и обработать.

h1. Как увидеть информацию о потерях

Ключевые слова: missed, dropped, fifo, error, rx.
{code}
ip -s -s link show eth1
{code}

Смотреть нужно на RX Errors. Некоторые сетевые карты предоставляют более подробную информацию о характере потерь:

{code}
ethtool -S eth1
{code}

Потери могут быть не только на сетевых картах Carbon Reductor. Они могут быть и на порту сетевого оборудования, отправляющего зеркало трафика. О том, как это посмотреть можно узнать из документации производителя сетевого оборудования.

h1. Нагрузка на процессор и что она значит

...
На постоянное использование можно добавлять команды в хук start.sh в функцию client_post_start_hook().

Итак, вещи:
h1. Network Top

{toc}
В комплекте с редуктором поставляется утилита

{code}
chroot /app/reductor network-top
{code}

Разберём их по порядку:
Запускается без аргументов, показывает полную картину нагрузки на сетевые карты и ядра процессора в реальном времени. Аномально высокие значения подсвечиваются желтым (больше нормы) или красным (критично) цветом.


h1. Размер буфера сетевой карты

...
{code}

Здесь мы видим выкрученный на максимум rx-буфер. Обычно подобрать значение довольно сложновато, ибо тут такая ситуация - либо задержки, либо потери, но нас задержки не волнуют, так как редуктор стоит сбоку от основного потока трафика, так что выкручиваем буфер на максимум. Пример команды для увеличения буфера.
Здесь мы видим увеличенный до максимума rx-буфер.

{code}
ethtool -G eth1 rx 4096
{code}
В Carbon Reductor DPI X при добавлении сетевой карты для фильтрации через мастер для неё автоматически настраивается оптимальный размер RX-буфера.

CentOS позволяет указывать параметры ethtool в качестве опции в настройках интерфейса (/etc/sysconfig/network-scripts/ifcfg-eth1), например строчкой
{code}
ETHTOOL_OPTS='-G eth1 rx 4096'
{code}
Также он настраивается автоматически при использовании опции FWBOOST.

К сожалению он не позволяет указывать несколько команд одновременно, но можно добавить их в хук.

h1. Распределение прерываний

Многие сетевые карты имеют несколько очередей для входящих пакетов. Каждая очередь висит на ядре/списке ядер. На многих железках из коробки, несмотря на то, что в smp_affinity_list указан список 0-$cpucount все прерывания находятся на первом ядре процессора. Обойти это можно раскидав с помощью echo все прерывания на разные ядра.
{include:reductor5:Распределение прерываний}

По возможности используйте разные реальные ядра, допустим, дано:
h1. Мощность ядер процессора

- 1 процессор с гипертредингом
- 4 реальных ядра
- 8 виртуальных ядер
- 4 очереди сетевой карты, которые составляют 95% работы сервера
В Carbon Reductor DPI X процессор автоматически настраивается на максимально доступную базовую частоту.

Раскинуть их на 0, 1, 2 и 3 ядра будет не так эффективно, как на 0, 2, 4 и 6.

Пример кода (костыльный и неуниверсальный), который раскидывает 8 очередей на 8 ядер (довольно простой случай).
Строка "-TxRx" - по ней можно идентифицировать очереди сетевой карты принимающей зеркало трафика, может отличаться в зависимости от модели сетевой карты и драйвера, посмотреть как она выглядит можно в файле cat /proc/interrupts

{code}
#!/bin/bash

tune_nic() {
echo "- Настраиваем прерывания $1"
local nic="$1$2"
local cpucount=$(grep -c 'model name' /proc/cpuinfo)
grep $nic /proc/interrupts | while read irq $(eval echo cpu{1..$cpucount}) _ queue _; do
irq=${irq//:}
proc_entry=/proc/irq/$irq/smp_affinity_list
evaled="${queue##*rx-}"
echo $evaled > $proc_entry
done
}

client_post_start_hook() {
tune_nic "eth1" "-rx"
tune_nic "eth2" "-TxRx"
}
{code}
h1. Настройки rx-usecs

h1. Мощность ядер процессора
В Carbon Reductor DPI X автоматически подбирается оптимальное значение этого параметра для сетевой карты при использовании опций FWBOOST.

{code}
[root@centos ~]# grep '' /sys/devices/system/cpu/cpu0/cpufreq/scaling_{min,cur,max}_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1600000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:3201000
{code}

Суть видна - довольно мощный процессор работает в полсилы и даже не собирается напрягаться.

Заставить их напрячься можно так:

{code}
#!/bin/bash
h1. Замена сетевых карт

cpucount=$(grep -c 'model name' /proc/cpuinfo)
sysdir=/sys/devices/system/cpu
for cpu in $(eval echo cpu{0..$((cpucount-1))}); do
cat $sysdir/$cpu/cpufreq/scaling_max_freq > $sysdir/$cpu/cpufreq/scaling_min_freq
done
{code}
Иногда бывает дело в используемом оборудовании. Если Вы уверены, что сетевая карта хорошей модели и есть ещё одна такая же - попробуйте использовать её. Возможно она просто бракованная.

h1. Различные значения rx-usecs
Иногда дело бывает в драйвере (в случае dlink / realtek сетевых карт). Они не подходят для высоких нагрузок.

Не буду плодить энтропию, так что вот ссылка на хорошую статью (правда заточенную под маршрутизаторы больше): [http://habrahabr.ru/post/108240/]
h1. Отключение гипертрединга

В некоторых случаях использование процессора с отключенным гипертредингом оказывалось эффективнее, чем с включенным, несмотря на меньшее количество логических ядер.

Делать это стоит, если все предыдущие пункты не помогают.


h1. Включение RPS

В Carbon Reductor DPI X эта технология автоматически настраивается для сетевых карт с одной очередью.

При использовании опции FWBOOST эта технология автоматически настраивается в сочетании с RSS.



h1. Актуализация настроек зеркала трафика

В кратце - можно за счёт повышения нагрузки на процессор слегка снять нагрузку с сетёвки уменьшая rx-usecs. На большинстве машин использумых в нашем случае оптимальным оказалось значение 1.
Разнесение всех интерфейсов зеркала трафика по отдельным бриджам даёт снижение нагрузки.

{code}
ethtool -C eth1 rx-usecs 1
{code}
h1. Использование нескольких сетевых карт для приёма зеркала

h1. Замена сетевых карт
Вы можете распределить зеркало между несколькими сетевыми картами, указав в настройках создаваемых сессий зеркалирования равные диапазоны абонентских физических портов.

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

Иногда дело бывает в драйвере (в случае dlink / realtek сетевых карт). Они, конечно, здорово поддерживаются практически любым дистрибутивом, но для высоких нагрузок не очень подходят.
h1. MTU

h1. Отключение гипертрединга
MTU на порту коммутатора, отправляющего зеркало не должно быть больше, чем MTU интерфейса на Carbon Reductor (в том числе и всех VLAN), принимающего зеркалированный трафик.

В некоторых случаях использование процессора с отключенным гипертредингом оказывалось эффективнее, чем с включенным, несмотря на меньшее количество логических ядер.
Рекомендуем посмотреть статистику на коммутаторе по распределению размеров пакетов, для D-Link например команда

Делать это стоит, если все предыдущие пункты не помогают.
{code}
show packet port 1:1
{code}

h1. NOTRACK (экспериментально)
и вывод в духе:

Если вы уверенны в отсутствии петель в зеркале (в Carbon Reductor не попадает его собственный трафик, можно проверить это с помощью tcpdump), то можно поэкспериментировать с этой опцией. Если в течении пары-тройки часов после включения проблем с выгрузкой и работой сети на Carbon Reductor не возникло, то её можно использовать. Она применяет ко всем пакетам идущим на интерфейсы во всех бриджах правило с \-j NOTRACK, что приводит к значительному снижению нагрузки на процессор.

Крупным провайдерам с большим объёмом трафика эта опция практически обязательна, почему - показывает пример:

ДО включения:
{code}
88.4%si
82.3%si
88.2%si
75.9%si
100.0%si
82.9%si
88.5%si
84.7%si
90.3%si
94.6%si
82.0%si
67.9%si
77.5%si
100.0%si
82.9%si
100.0%si
82.0%si
100.0%si
85.0%si
93.8%si
90.3%si
91.2%si
89.3%si
100.0%si
87.3%si
97.3%si
91.1%si
94.6%si
100.0%si
87.6%si
81.7%si
85.7%si
Port number : 2:11
Frame Size/Type Frame Counts Frames/sec
--------------- ---------------------- -----------
64 1470536789 6330
65-127 511753536 12442
128-255 1145529306 1433
256-511 704083758 1097
512-1023 842811566 882
1024-1518 1348869310 7004
1519-1522 2321195608 1572
1519-2047 2321195608 1572
2048-4095 0 0
4096-9216 0 0
Unicast RX 0 0
Multicast RX 16 0
Broadcast RX 0 0
Frame Type Total Total/sec
--------------- ---------------------- -----------
RX Bytes 1384 0
RX Frames 16 0
TX Bytes 20409818277370 15162751
TX Frames 34114583632 30760
{code}

ПОСЛЕ включения:
По дефолту, CentOS ставит MTU = 1500, лучше выставить его равным максимальному ненулевому значению из статистики.

{code}
1.2%si
2.4%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
1.3%si
1.2%si
0.0%si
1.2%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
1.4%si
0.0%si
1.3%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
0.0%si
1.4%si
1.5%si
0.0%si
1519-2047 2321195608 1572
{code}

h1. Включение RPS (актуально для realtek/dlink/бюджетных intel)
h2. Как определить потери пакетов из-за низкого MTU?

Мы в скором времени постараемся сделать автоматическую настройку при необходимости.
Посмотрите на RX: length значение.

Пока можно включить руками или добавив в хук команду в духе:

{code}
cpucount="$(grep -c 'model name' /proc/cpuinfo)"
printf "%x\n" $((2**cpucount-1)) > /sys/class/net/eth1/queues/rx-0/rps_cpus
# ip -s -s link show eth1
3: eth1: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1528 qdisc mq state UP qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
5956390755888 19345313821 3533855 0 0 817154
RX errors: length crc frame fifo missed
3533855 0 0 0 0
TX: bytes packets errors dropped carrier collsns
23100 330 0 0 0 0
TX errors: aborted fifo window heartbeat
0 0 0 0
{code}

h1. Актуализация настроек зеркала трафика
Как избавиться от этих потерь?

Разнесение всех интерфейсов зеркала трафика по отдельным бриджам даёт небольшое снижение нагрузки за счёт устранения небольшой петли.

h1. Использование нескольких сетевых карт для приёма зеркала
Разово:

Вы можете раскидать зеркало между несколькими сетевыми картами, указав в настройках создаваемых зеркал равные диапазоны абонентских портов.
{code}
ip link set eth1 mtu 1540
{code}

h1. Отключение логирования
На постоянной основе:

menu > настройки алгоритма фильтрации > логировать срабатывания
Дописать в конфиг сетевой карты (например /etc/sysconfig/network-scripts/ifcfg-eth1):

отключите эту опцию, это _немного_ ускорит процесс обработки пакета и отправки редиректа. Однако несмотря на "немного", при очень частых срабатываниях - способно даже немного снизить нагрузку на процессор.
{code}
MTU=1540
{code}