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

{code}
top -cd1
{code}

h2. Процессоры

Частые проблемы в настройках процессора.

h3. "Плавающая" частота

{code}
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

h2. Сетевые карты

h3. Размер буфера

{code}
# ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 256

{code}
ethtool -G eth1 rx 2048

ETHTOOL_OPTS="-G ${DEVICE} rx 2048"
{code}

Альтернативный вариант с автоматическим определением оптимального значения (утилита из netutils-linux):

{code}
rx-buffers-increase eth1
{code}

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

rss-ladder eth1

h5. Пример для Carbon Reductor 8

Мы не используем автоматическую настройку RSS, т.к. в редких ситуациях это приводит к зависанию сетевой карты. Так что настраивать это необходимо вручную:

Создаем сам файл-хук: `/app/reductor/cfg/userinfo/hooks/start.sh`

В него добавляем следующее содержимое:

{code}
#!/bin/bash

Существует технология программного распределения обрабатываемых пакетов между ядрами - RPS. Она универсальна и подходит для любых сетевых карт, даже с одной очередью. Пример настройки:

{code}
autorps eth2
{code}

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

{code}

h3. Опции несовместимые с FORWARD / bridge

General Receive Offload и Large Receive Offload могут приводить к паникам ядра Linux и их лучше отключать:

{code}
ethtool -K eth2 gro off
ethtool -K eth2 lro off
{code}

Либо при компиляции драйвера.

h3. Веса очередей (RX Flow Indirection)

В ситуации с одной активной сетевой картой и двумя физическими процессорами с разными NUMA-нодами имеет смысл снизить нагрузку на "чужую" NUMA-ноду.

Настраивается с помощью ethtool, очередям задаются веса, не все сетевые карты это поддерживают.

Экспериментов пока было не так много, но оптимальным кажется сочетание весов: 3 на ядра своей ноды, 2 на ядра чужой, так как обращения к оперативной памяти чужой NUMA-ноды медленнее, чем к своей.

Пример - допустим у нас есть 2 двухядерных процессора и сетевая карта eth2, поддерживающая 4 очереди. CPU0, CPU1 - это её локальная нода, CPU2, CPU3 - чужая.

{code}
# посмотреть текущие настройки
ethtool -x eth2
# настроить
ethtool -X eth2 weight 3 3 2 2
{code}
Обязательно проверяйте после этих изменений что всё работает так, как и ожидалось с помощью утилиты network-top.

h3. Замена сетевых карт

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

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

h2. Сетевой стек, iptables

h3. NOTRACK

Эта технология отключает наблюдение за состоянием соединения для пакетов к которым она была применена. Это приводит к значительному снижению нагрузки на процессор в случае, если состояние соединения нас не интересует (захват трафика).

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

h4. ДО включения:

{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
{code}

h4. ПОСЛЕ включения:

{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
{code}

h2. Сеть провайдера

h3. Масштабирование


h4. В рамках одного сервера

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

Обычно это имеет смысл в случае если сервер имеет несколько физических процессоров и несколько сетевых карт (несколько портов одной карты привязываются к одному и тому же процессору, использование "чужого процессора" ведёт к меньшей производительности).

h4. Между серверами

{color:#333333}Вы можете располагать сетевые карты из пункта выше в разных серверах для масштабирования нагрузки.{color}

h3. Flow-control

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

{code}
ethtool -A eth2 rx off tx off
{code}

В Carbon Reductor 8 скоро будет доступно в автоматическом режиме.

h3. MTU

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

Рекомендуем посмотреть статистику на свитче по распределению размеров пакетов, для D-Link например команда `show packet port 1:1`

и вывод в духе:

По умолчанию CentOS используется MTU = 1500, лучше выставить его равным максимальному ненулевому значению из статистики.

h4. Как определить потери пакетов из-за низкого MTU?

Смотрите на RX: length значение в выводе команды:

{code}

h4. Как избавиться от этих потерь?

\**Разово*\* - выполнить команду:

{code}
ip link set eth1 mtu 1540
{code}

\**Перманентно*\* - дописать в настройки сетёвой карты `/etc/sysconfig/network-scripts/ifcfg-eth1`:

{code}
MTU=1540
{code}

h2. Carbon Reductor

h3. Опции снижающие производительность

- menu > настройки алгоритма фильтрации > логировать срабатывания
- menu > настройки алгоритма фильтрации > сохранять домен в адресе редиректа

Они замедляют процесс обработки пакета и отправки редиректов.