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

Skip to end of metadata
Go to start of metadata

В Linux сетевое оборудование (процессор, сетевые карты) по умолчанию работает неидеально. Наша задача - поймать пакеты, не упустив ни одного и обработать, при этом желательно в реальном времени.

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

Для начала убедимся в существовании проблемы. Для этого будем использовать набор утилит в Carbon Reductor и стандартные инструменты iproute.

Все команды надо запускать перейдя в контейнер Carbon Reductor:

chroot /app/reductor

Информация о конкретной сетевой карте

ip -s -s link show eth2
6: eth2: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:e0:ed:33:65:b2 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    66192704908009 358590458063 0       0       0       79155
    RX errors: length   crc     frame   fifo    missed
               0        0       0       0       111495719
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0
    TX errors: aborted  fifo   window heartbeat
               0        0       0       0

Смотреть нужно на все виды RX Errors.

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

ethtool -S eth2 | egrep rx_ | grep -v ': 0$' | egrep -v 'packets:|bytes:'
     rx_pkts_nic: 365565232680
     rx_bytes_nic: 69973509621284
     rx_missed_errors: 111495719
     rx_long_length_errors: 1077
     rx_csum_offload_errors: 169255
     rx_no_dma_resources: 383638

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

Как интерпретировать нагрузку на процессор

Выполните команду

top -cd1

и нажмите клавишу "1", чтобы увидеть информацию о каждом конкретном процессоре.

Формат вывода следующий:

Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 88.0%id,  0.0%wa,  0.0%hi, 12.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 88.8%id,  0.0%wa,  0.0%hi, 11.2%si,  0.0%st
Cpu2  :  0.0%us,  1.0%sy,  0.0%ni, 85.0%id,  0.0%wa,  0.0%hi, 14.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 87.8%id,  0.0%wa,  0.0%hi, 12.2%si,  0.0%st

Интерес представляет колонка "%si".

Если нагрузка распределена неравномерно, т.е. Cpu0 трудится, а 1..n нет, то ресурсы процессора используются нерационально.

  • 0% на каждом ядре - возможно на сервере нет трафика.
  • 1-3% - увеличение канала возможно без апгрейда оборудования.
  • 6-10% - текущая нагрузка обрабатывается нормально, увеличение канала потребует апгрейд  оборудования.
  • 11-15% - вероятно требуется апгрейд оборудования или оптимизации настроек имеющегося.
  • 20-100% - с вероятностью 99% присутствуют потери пакетов. Если ситуация сохраняется после применения последующих пунктов этой статьи - свяжитесь с технической поддержкой.

Информация о сетевом стеке

Просмотр подробной информации о текущем состоянии сетевого стека:

network-top

Некоторые значения подсвечиваются жёлтым (высокое значение) и красным (чрезвычайно высокое значение или ошибка). Это эвристика и не подстраивается под конкретный сервер.

При количестве ядер больше 20 или большом числе VLAN информация может не влезать на экран, решение проблемы - уменьшить масштаб терминала или перечислить необходимые девайсы `--devices=eth1,eth2,eth3`:

Вывод выглядит так:

[root@reductor support]# network-top -n 1 --no-clear --no-color
# /proc/interrupts

   CPU0    CPU1    CPU2    CPU3    CPU4    CPU5    CPU6    CPU7    CPU8    CPU9   CPU10   CPU11   CPU12   CPU13   CPU14   CPU15

      0       0       0       0       0       0       0     733       0       0       0       0       0       0       0       0   eth0-TxRx-7
  39405       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-0
      0   39768       0       0       0       0       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-1
      0       0   38518       0       0       0       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-2
      0       0       0   41302       0       0       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-3
      0       0       0       0   39061       0       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-4
      0       0       0       0       0   42078       0       0       0       0       0       0       0       0       0       0   eth2-TxRx-5
      0       0       0       0       0       0   39168       0       0       0       0       0       0       0       0       0   eth2-TxRx-6
      0       0       0       0       0       0       0   39294       0       0       0       0       0       0       0       0   eth2-TxRx-7
      0       0       0       0       0       0       0       0   37167       0       0       0       0       0       0       0   eth2-TxRx-8
      0       0       0       0       0       0       0       0       0   37460       0       0       0       0       0       0   eth2-TxRx-9
      0       0       0       0       0       0       0       0       0       0   40164       0       0       0       0       0   eth2-TxRx-10
      0       0       0       0       0       0       0       0       0       0       0   39613       0       0       0       0   eth2-TxRx-11
      0       0       0       0       0       0       0       0       0       0       0       0   40362       0       0       0   eth2-TxRx-12
      0       0       0       0       0       0       0       0       0       0       0       0       0   41184       0       0   eth2-TxRx-13
      0       0       0       0       0       0       0       0       0       0       0       0       0       0   42319       0   eth2-TxRx-14
      0       0       0       0       0       0       0       0       0       0       0       0       0       0       0   38430   eth2-TxRx-15
    111      61      31      70      23      86      45      77     166       0      12      15      21       9       0     112   interrupts

# Load per cpu:

  CPU     Interrupts   NET RX   NET TX    total   dropped   time_squeeze   cpu_collision   received_rps

  CPU0         39545    39717        0   127558         0              0               0              0
  CPU1         39845    40164        0   130904         0              0               0              0
  CPU2         38594    38925        0   133087         0              0               0              0
  CPU3         41411    41702        0   155217         0              0               0              0
  CPU4         39118    39388        0   126653         0              0               0              0
  CPU5         42188    42443        0   141257         0              0               0              0
  CPU6         39230    39527        0   137838         0              0               0              0
  CPU7         40118    40425        0   117886         0              0               0              0
  CPU8         37335    37430        0   118963         0              0               0              0
  CPU9         37464    37535        0   144810         0              0               0              0
  CPU10        40194    40463        0   135276         0              0               0              0
  CPU11        39630    39953        0   136303         0              0               0              0
  CPU12        40387    40675        0   135858         0              0               0              0
  CPU13        41195    41526        0   134899         0              0               0              0
  CPU14        42321    42705        0   156010         0              0               0              0
  CPU15        38593    38695        0   113177         0              0               0              0

# Network devices

  Device      rx-packets   rx-mbits   rx-errors   dropped   missed   fifo   length   overrun   crc   frame   tx-packets   tx-mbits   tx-errors

  lo                   0          0           0         0        0      0        0         0     0       0            0          0           0
  eth0                21          0           0         0        0      0        0         0     0       0         1155          1           0
  eth1                 0          0           0         0        0      0        0         0     0       0            0          0           0
  eth2           1082133       1462           0         0        0      0        0         0     0       0            0          0           0
  eth3                 0          0           0         0        0      0        0         0     0       0            0          0           0

Данные собираются из нескольких источников (`/proc/interrupts`, `/proc/softirqs`, `/proc/net/softnet_stat` и др) и представленны в удобочитаемом виде. По умолчанию отображаются изменения по сравнению с предыдущими значениями. Режим `--no-delta-mode`, отображает абсолютные значения.

/proc/interrupts

Отображает то, как очереди сетевой карты распределены между ядрами. Рекомендуем распределять 1 очередь на 1 ядро, можно "лесенкой".

Если в одну очередь приходит больше пакетов, чем в остальные - возможно трафик инкапсулирован (QinQ, PPP).

Load per CPU

Отображает что делает каждое ядро. Распределение обработки трафика может достигается за счёт очередей сетевой карты (RSS) или технологии RPS ("программный" RSS).

  • Interrupts - прерывания, это копирование пакетов из сетевой карты в оперативной памяти.
  • NET_RX - отложенная обработка входящего трафика: собственно обработка пакетов файрволом
  • Total - число обрабатываемых пакетов
  • dropped - потери пакетов
  • time_squeeze - задержки пакетов - пакет не успел обработаться за отведённое время, отложен для обработки позже. Наличие задержек - признак того, что сервер перестаёт справляться с нагрузкой.

Network devices

Статистика по сетевым картам

  • rx-errors - общее число ошибок, суммирует остальные. В какой счётчик попадает потерявшийся пакет зависит от драйвера сетевой карты.
  • dropped, fifo, overrun - как правило, пакеты, не успевшие обработаться сетевым стеком
  • missed - как правило, пакеты, не успевшие попасть в сетевой стек
  • length - как правило слишком большие пакеты, которые не влезают в MTU на сетевой карте. Лечится увеличением MTU.
  • crc - прилетают битые пакеты. Часто - следствие высокой нагрузки на коммутатор.

Что, как и когда настраивать

Процессоры

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

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

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

Проблема - процессор работает вполсилы. Исправить это можно используя утилиту `maximize-cpu-freq` входящую в netutils-linux, в Carbon Reductor 8 она используется автоматически.

Режим энергосбережения

Ещё одно "но", которое приводит к проблемам и которое сложно выяснить программным путём - режим энергосбережения в UEFI или BIOS, который у некоторых процессоров Intel Xeon приводил напротив, к повышению нагрузки. Лучше выключить эту опцию, выбрав режим "производительность" (для этого потребуется перезагрузить сервер).

DCA

Владельцам процессоров Intel Xeon и сетевых карт Intel 82599 (а также многих других 10Гбит/сек сетевых карт от Intel) стоит проверить настройки DCA в BIOS/UEFI, эта опция может дать приблизительно 5-10% производительности. Включен он или нет можно посмотреть командами (после запуска):

dmesg | egrep -i dca

Если включен, в выводе будет:

dca service started, version 1.8

Если выключен:

ioatdma 0000:00:08.0: DCA is disabled in BIOS

Гипертрединг

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

Низкая частота

Процессоры с большим числом ядер, но низкой частотой - 2 - 2.2GHz не подходят для сетевых задач с низкими задержками. Низкая частота приводит к медленной обработке отдельно взятого пакета, которая не масштабируется с числом ядер. Иными словами, числом ядер невозможно побороть задержки в обработке пакетов.

Что с этим делать - лучше не покупать такие процессоры, они созданы для других задач. Если он уже куплен - поискать ему другое применение.

Оптимальная частота для процессоров используемых для сетевых задач - 3GHz+, но чем выше - тем лучше.

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

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

# 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

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

Пример команд для увеличения буфера:

ethtool -G eth1 rx 2048

В RHEL-based дистрибутивы (платформа Carbon, CentOS, Fedora итд) укажите параметры ethtool в настройках интерфейса (`/etc/sysconfig/network-scripts/ifcfg-eth1`) строчкой:

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

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

rx-buffers-increase eth1

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

Реальные прерывания

Хорошие сетевые карты поддерживают несколько очередей для входящих пакетов. Каждая очередь привязана к одному или нескольким ядрам. Несмотря на указанный список зачастую сетевые карты по умолчанию коробки работают на первом ядре процессора. Обойти это можно распределив прерывания c помощью утилиты rss-ladder.

rss-ladder eth1

Используйте разные ядра (cores), гипертрединг лучше выключить, с ним легко получить неоптимальные настройки.

Многопроцессорные системы

Если в системе больше одного физического процессора, лучше распределять прерывания сетевой карты в пределах ядер её локальной NUMA-ноды. rss-ladder делает это автоматически. Число очередей лучше подстроить под число ядер одного физического процессора, по умолчанию их число часто равно общему числу ядер.

Пример - поставим eth2 8 объединённых очередей.

ethtool -L eth2 combined 8

Очереди бывают combined или отдельные tx и rx, зависит от модели и драйвера сетевой карты.

Не все многопроцессорные системы поддерживают NUMA, иногда память является общей для обоих процессоров и для сетевых карт.

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

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

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

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

#!/bin/bash

client_post_start_hook() {
    rss-ladder eth0 || true
    rss-ladder eth1 || true
}

и делаем файл исполнимым: `chmod a+x /app/reductor/cfg/userinfo/hooks/start.sh`.

Отложенные прерывания

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

autorps eth2

В Carbon Reductor 8 данная утилита используется автоматически для сетевых карт с одной очередью.

Различные значения rx-usecs

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

Статья для лучшего понимания, правда больше под маршрутизаторы : http://habrahabr.ru/post/108240/

В кратце - можно за счёт повышения нагрузки на процессор слегка снять нагрузку с сетевой карты, уменьшая rx-usecs.

На большинстве машин использумых в нашем случае оптимальным оказалось значение 1.

ethtool -C eth1 rx-usecs 1

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

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

ethtool -K eth2 gro off
ethtool -K eth2 lro off

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

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

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

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

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

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

# посмотреть текущие настройки
ethtool -x eth2
# настроить
ethtool -X eth2 weight 3 3 2 2

Обязательно проверяйте после этих изменений что всё работает так, как и ожидалось с помощью утилиты network-top.

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

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

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

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

NOTRACK

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

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

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

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

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

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

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

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

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

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

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

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

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

Flow-control

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

ethtool -A eth2 rx off tx off

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

MTU

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

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

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

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

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

 1519-2047             2321195608                    1572

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

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

# 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

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

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

ip link set eth1 mtu 1540

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

MTU=1540

Carbon Reductor

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

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

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

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.