Rx packets ошибки

Это краткий обзор утилит.

1. ifconfig
2. route
3. ping
4. nslookup
5. traceroute
6. mtr

1.ifconfig
Как посмотреть состояние интерфейсов?
Как посмотреть ip адрес?
Как посмотреть mac адрес?
Как посмотреть маску?
Как посмотреть MTU?

Все это можно сделать при помощи одной утилиты.

[root@yourhostname ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0C:29:D8:9C:11
inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:2207 errors:0 dropped:0 overruns:0 frame:0
TX packets:2456 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:181021 (176.7 KiB)  TX bytes:323884 (316.2 KiB)
Interrupt:169 Base address:0x1080

lo        Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1136 (1.1 KiB)  TX bytes:1136 (1.1 KiB)

Посмотрите на вывод команды первое слово это название вашего интерфейса. Чтобы вывести информацию о конкретном интерфейсе нужно выполнить команду ifconfig название интерфейса

[root@yourhostname ~]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0C:29:1E:D8:18
inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:1357 errors:0 dropped:0 overruns:0 frame:0
TX packets:606 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:112009 (109.3 KiB)  TX bytes:91115 (88.9 KiB)
Interrupt:169 Base address:0x1080

Link encap:Ethernet — метод инкапсуляции Ethernet
HWaddr 00:0C:29:1E:D8:18 сокращение от Hardware addres или по другому Mac адрес
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 ip адрес, широковещательный адрес, маска подсети.
UP BROADCAST RUNNING MULTICAST Означает что ваш интерфейс включен, поддерживает широковещание BROADCAST и групповую передачу MULTICAST
MTU:1500 MTU
Metric:1

метрику — числовой показатель, задающий предпочтительность маршрута. Чем меньше число, тем более предпочтителен маршрут (интуитивно представляется как расстояние).
Wikipedia Таблица маршрутизации

RX packets:1357 errors:0 dropped:0 overruns:0 frame:0 RX resive получено, packets пакеты, errors ошибки, dropped количество отклоненных пакетов, overruns переполнение очереди, frame неверный формат пакетов.
TX packets:606 errors:0 dropped:0 overruns:0 carrier:0 TX Transmit отправлено, packets пакеты, errors ошибки, dropped количество отклоненных пакетов, overruns переполнение очереди, carrier ошибки несущей частоты.
collisions:0 txqueuelen:1000 collisions коллизии, txqueuelen длина очереди передачи для устройства.

2.route
Как посмотреть таблицу маршрутизации?
Как посмотреть шлюз по умолчанию?
Таблицу маршрутизации можно посмотреть командой route.

[root@yourhostname ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

Destination адрес назначения ip сети или ip хоста
Gateway шлюз * если не задан
Genmask маска подсети для хоста маска будет 255.255.255.255
Flags доступные флаги U маршрут включен, H цель хост, G используется шлюз, R восстановить маршрут для динамической маршрутизации, D динамически установлен демоном или перенаправлением, M изменен демоном или перенаправлением, A установлен утилитой addconf, С запись из кеша, ! игнорировать маршрут.
Metric Метрика
Ref Количество ссылок на этот маршрут. (Не используется в ядре Linux.)
Iface интерфейс через который будут проходить пакеты.
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 Это и есть наш шлюз по умолчанию.

3.ping
Самая простая утилита для проверки доступности хоста. Используется протокол ICPM
Синтаксис ping [опции] имя хоста или его ip адрес
В отличии от аналогичной утилиты в Windows в Lnux-е утилита будет работать до тех пор пока вы явно не прервете. Чтобы прервать выполнение нужно нажать сочетание клавиш Ctrl+c
Проверяем доступность шлюза.

[root@yourhostname ~]# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.90 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=1.37 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=1.61 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.978 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=1.23 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=1.86 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=1.44 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=1.58 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=1.10 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=1.57 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=1.61 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=1.54 ms

--- 192.168.0.1 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11007ms
rtt min/avg/max/mdev = 0.978/1.569/2.902/0.465 ms

Вывод читается следующим образом.
PING 192.168.0.1{имя хоста} (192.168.0.1{ip адрес}) 56{размер данных в байтах}(84{размер пакета в байтах |данные+заголовок icmp+заголовок IP| 56+8+20}) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.90 ms Получено 64 байт от хоста 192.168.0.1, пакет №1, время жизни пакета 64(ttl) за время 2.90 миллисекунд
— 192.168.0.1 ping statistics —
12 packets transmitted, 12 received, 0% packet loss, time 11007ms
rtt min/avg/max/mdev = 0.978/1.569/2.902/0.465 ms статистика пинга 12 пакетов отправлено 12 получено 0% потерь, затраченное время 11007 миллисекунд.
rtt ((RTT, от англ. Round Trip Time) позволяет определять двусторонние задержки минимальная задержка 0.978, среднее значение 1.569, максимальная задержка 2.902, среднее отклонение (mdev для потоковых сервисов таких как skype, youtube, онлайн игры данный параметр наряду с задержкой играет важную роль, по сути он означает стабильность канала.) 0.465
Также проверим доступность DNS сервера.
Что если мы хотим отправить определенное количество пакетов например 10? Для этого нам нужно использовать опцию -c количество пакетов

[root@yourhostname ~]# ping -c 10 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=51 time=279 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=51 time=305 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=51 time=225 ms
64 bytes from 8.8.4.4: icmp_seq=4 ttl=51 time=304 ms
64 bytes from 8.8.4.4: icmp_seq=5 ttl=51 time=291 ms
64 bytes from 8.8.4.4: icmp_seq=6 ttl=51 time=277 ms
64 bytes from 8.8.4.4: icmp_seq=7 ttl=51 time=291 ms
64 bytes from 8.8.4.4: icmp_seq=8 ttl=51 time=294 ms
64 bytes from 8.8.4.4: icmp_seq=9 ttl=51 time=308 ms
64 bytes from 8.8.4.4: icmp_seq=10 ttl=51 time=308 ms

--- 8.8.4.4 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 225.374/288.686/308.575/23.670 ms

Пингом можно пофлудить мягко с помощью опции -i интервал в секунадх и жестко с помощью опции -f.

[root@yourhostname ~]# ping -c 10 -i 0.001 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=52 time=75.6 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=52 time=75.9 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=52 time=76.0 ms
64 bytes from 8.8.4.4: icmp_seq=4 ttl=52 time=81.6 ms
64 bytes from 8.8.4.4: icmp_seq=5 ttl=52 time=82.2 ms
64 bytes from 8.8.4.4: icmp_seq=6 ttl=52 time=84.3 ms
64 bytes from 8.8.4.4: icmp_seq=7 ttl=52 time=84.1 ms
64 bytes from 8.8.4.4: icmp_seq=8 ttl=52 time=86.0 ms
64 bytes from 8.8.4.4: icmp_seq=9 ttl=52 time=85.8 ms
64 bytes from 8.8.4.4: icmp_seq=10 ttl=52 time=86.2 ms

--- 8.8.4.4 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 87ms
rtt min/avg/max/mdev = 75.607/81.818/86.251/4.165 ms, pipe 8

Было послано 10 пакетов 0% потерь за время 87 миллисекунд, минимальная задержка 75.607 мс, средняя 81.818мс, максимальная 86.251мс, среднее отклонение 4.165(его еще называют jitter или по русски дрожанием канала), новый параметр pipe точного ответа что этот параметр обозначает я к сожалению не нашел, наиболее вероятный ответ на мой взгляд это количество потоков которые обработали ICMP запросы.
Давайте пофлудим

[root@yourhostname SOURCES]# ping  -c10 -f 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.

--- 8.8.4.4 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 111ms
rtt min/avg/max/mdev = 76.611/79.931/81.929/1.472 ms, pipe 7, ipg/ewma 12.360/80.157 ms

Было послано 10 пакетов, вернулось 10 паетов, 0% потерь, за время 111мс, мин задержка 76.611, средняя 79.931мс, максимальная 81.929мс, среднее отклонение 1.472мс, pipe 7, ipg интервал между кадрами(этот интервал предназначен для того чтобы адаптер подготовился к принятию следующего кадра(фрейма) чтобы избежать колизий) 12.360мс, ewma (экспоненциально взвешенное скользящее среднее) это почти тоже самое что и среднее значение только для каждого пакета указан его вес(значимость), более поздние пакеты имеют больший вес чем более ранние. Сравнив среднее значение с ewma мы может сделать вывод что задержка увеличилась в конце пинга 79.931<80.157.
Очень аккуратно используйте опции -i и -f это может противоречить законодательству вашей страны и договору с провайдером см тут.
4.nslookup
Проверим работоспособность нашего DNS.

[root@yourhostname ~]# nslookup google.com
Server:         8.8.4.4
Address:        8.8.4.4#53

Non-authoritative answer:
Name:   google.com
Address: 74.125.79.104
Name:   google.com
Address: 74.125.79.99
Name:   google.com
Address: 74.125.79.147

Первые две строки это ip адрес и порт DNS сервера с которого была получена информация.
Non-authoritative answer: означает что данный DNS не отвечает за зону то есть не является primary для доменного имени google.com
Далее мы видим что google.com доступен по трем ip адресам 74.125.79.104, 74.125.79.99, 74.125.79.147
5.traceroute

Traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP. Traceroute основана на протоколе ICMP.
Wikipedia

Очень хорошо про traceroute написано тут.
В CentOs по умолчанию traceroute работает по протоколу UDP чтобы использовать протокл ICMP нужно указать опцию -I.
6.mtr
mytraceroute
Инструмент вобравший в себя возможности утилит traceroute и ping. Строиться маршрут следования, после чего кажды узел маршрута пингуеться. Маршрут следования вычисляется после каждого цикла.
Давайте пробовать.

[root@yourhostname ~]# mtr google.com

Команда без дополнительных опций будет выполняться то тех пор пока вы не прервете ее выполнение нажатие клавиши q (quit). При этом результат не будет сохранен на экране. Чтобы получить отчет нужно добавить опцию -r(—report). При это вы не увидите хода выполнения программы а получите только готовый результат. По умолчанию отправляется 10 пакетов.

[root@yourhostname ~]# mtr -r google.com
yourhostname                      Snt: 10    Loss%  Last   Avg  Best  Wrst StDev
192.168.0.1                                   0.0%   3.0   2.3   1.4   3.0   0.5
???                                          100.0   0.0   0.0   0.0   0.0   0.0
94.141.64.125                                 0.0%  34.0  44.8  34.0  98.3  19.0
94.141.64.158                                 0.0%  38.9  44.2  32.1  75.3  14.0
94.141.64.161                                 0.0%  49.3  41.1  27.4  49.3   6.2
80.80.209.149                                 0.0%  32.4  70.5  29.1 311.3  86.9
80.80.209.2                                   0.0%  42.8  57.4  11.6 244.3  66.4
195.69.188.146                                0.0%  41.9  53.2  25.5 176.3  44.7
82.200.157.249                               10.0% 103.5 103.7  56.6 119.1  18.3
???                                          100.0   0.0   0.0   0.0   0.0   0.0
82.200.154.222                                0.0%  93.3 100.8  93.3 107.6   4.0
209.85.255.176                                0.0% 102.0 104.3  96.4 112.6   5.3
209.85.254.116                                0.0%  98.0 102.6  97.4 110.4   4.4
209.85.249.166                               50.0% 108.9 108.9  99.2 119.9   8.8
fx-in-f105.1e100.net                         10.0% 106.1 109.4 100.3 132.3  10.5

Расшифровываем.
Snt: 10 было послано 10 пакетов.
Loss% потеряно в %.
Last последний пинг мс.
Avg средняя задержка мс.
Best лучший пинг мс.
Wrst (worst) худший пинг мс.
StDev Стандартное отклонение тоже само что и среднее.
Чтобы отправить определенное количество пакетов воспользуйтесь опцией -c

Большинство настроек производительности сервера Carbon Reductor настраивает автоматически, но некоторые нужно подстраивать под конкретный сервер вручную. Если Ваш сервер перестал справляться с нагрузкой или вы хотите повысить запас производительности сервера, воспользуйтесь советами из этой статьи.

Как оценить производительность сервера

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

Все команды надо запускать перейдя в контейнер Carbon 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

Обращать внимание нужно не только на наличие ошибок, но и на скорость их появления: например, они могут появиться разово во время настройки сетевой карты.

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

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

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

и нажмите клавишу «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 нет, то ресурсы процессора используются нерационально.

Показатель «%si» растет нелинейно при повышении нагрузки. Чем больше в Вашем сервере ядер — тем больше они влияют друг на друга и тем сильнее растет «%si».

Если значение стабильно выше 60-80% — что сервер работает практически на пределе. Если подходит к 100% — сервер начинает плохо справляться с фильтрацией (пакеты начинают теряться или обрабатываются с задержкой).

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

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

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

При количестве ядер больше 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

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

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

Load per CPU

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

• Interrupts — прерывания от сетевой карты
• NET_RX — отложенная обработка входящего трафика: собственно обработка пакетов файрволом
• Total — число обрабатываемых пакетов
• dropped — потери пакетов
• time_squeeze — количество дополнительных циклов обработки пакетов из 1 прерывания. При наличии потерь, косвенно указывает что именно ядро не справляется с обработкой пакетов (при большом количестве циклов, более 100-300)

Network devices

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

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

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

Процессоры

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

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

У многих процессоров существует режим энергосбережения в UEFI или BIOS. Это трудно определить программным путем, поэтому лучше сразу, при настройке сервера, выключить эту опцию, выбрав режим «производительность».

DCA

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

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

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-буфер. В нашем случая оптимальное — максимальное значение, но иногда мы уменьшаем это значение, чтобы ускорить обработку пакетов.

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

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

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

Альтернативный вариант с автоматическим определением оптимального значения:

chroot /app/reductor/
rx-buffers-increase eth1

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

Включение из консоли:

Шаг 1. Выбрать пункт «Включить RSS для сетевых карт»

menu->Reductor DPI X->Прочие настройки->Включить RSS для сетевых карт

Далее выйти с сохранением настроек.

Шаг 2. Проверить запись в mirror_info.conf

Открыть любым удобным для вас редактором ( например vim ) файл mirror_info.conf

vim /app/reductor/cfg/userinfo/mirror_info.conf

Убедиться в наличие соответствующей записи «mirror rss» напротив каждого указанного интерфейса.

Шаг 3. Рестарт редуктора

/app/reductor/service restart

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

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

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

Комбинирование RSS и RPS

Перед настройками зафиксируйте средний рост потерь с помощью команды network-top ( chroot /app/reductor/ network-top ). После замеров сравните, как этот показатель изменился. Оптимизация без замеров может ухудшить ситуацию!

В случае если:

1. Используется одна сетевая карта
2. Сетевая карта не привязана к конкретной NUMA-ноде (команда cat /sys/class/net/eth0/device/numa_node выводит «-1»)
3. Система имеет 2+ физических процессора
4. Один процессор не справляется с нагрузкой
5. При использовании распределения реальных прерываний по ядрам обоих процессоров потерь становится ещё больше

Можно попробовать комбинировать RSS и RPS.

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

• Для 4 ядер — f
• Для 8 ядер — ff
• Для 12 ядер — fff
• Маску можно посмотреть в файле /sys/class/net/eth0/device/local_cpus

Все примеры ниже — для 2х 6-ядерных процессоров

chroot /app/reductor
rss-ladder eth0
autorps eth0 -m fff -f

Чтобы эффект сохранялся после перезагрузки нужно в хуке /app/reductor/cfg/userinfo/hooks/start.sh добавить следующее:

#!/bin/bash

client_post_start_hook() {
    ethtool -L eth0 combined 6 || true
    rss-ladder eth0 || true
    autorps eth0 -m fff -f || true
    return 0
}

Если ситуация стала хуже, RPS можно отключить, указав маску = 0:

Совместимость VLAN и RSS

Некоторые сетевые карты направляют все пакеты с одного VLAN в одну и ту же очередь, так как RSS hashing вычисляет один и тот же хэш для этих пакетов.

Некоторые карты умеют обрабатывать только VLAN первого уровня, но при использовании QinQ сталкиваются с той же проблемой.

Решения бывают разные:

• найти драйвера с поддержкой RSS+VLAN, сделанные сообществом.
• сменить сетевые карты на другую модель, которая поддерживает VLAN лучше.
• отказаться от VLAN, зеркалируя чистый трафик, без VLAN-тегов, либо снимать их при зеркалировании.
  • в случае с QinQ может оказаться достаточно снять один тег.
• использовать распределение нагрузки с помощью RPS, используя для захвата одно ядро (экспериментальная опция fwboost: isolated rss).

Большое число VLAN

При большом количестве VLAN создаётся большое количество правил iptables в цепочке iptables -t raw -nvL PREROUTING.

Их число можно сократить, перечислив через пробел интерфейсы с большим числом VLAN-тегов в опции: menu -> Reductor DPI X -> Настройки алгоритма фильтрации -> Интерфейсы с большим количеством VLAN.

Опция позволяет добиться 1-3% прироста производительности.

Различные значения 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 gso 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

Эта опция включена по-умолчанию, выключать ее можно только в исключительных случаях.

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

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

Проверить это можно:

1. посмотрев объёмы трафика по сетевым картам с помощью утилиты link-rate
2. проверив, что все сетевые карты, принимающие зеркало трафика, имеют ссылку в цепочку mirror_traffic с помощью команды iptables -t raw -nvL PREROUTING

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

Отправлять меньше трафика

Проанализируйте что вы отправляете в зеркало. Возможно там есть что-то лишнее.

1. Иногда один и тот же трафик попадает в зеркало дважды — инкапсулированным и чистым, в таком случае от инкапсулированного можно избавиться.
2. Возможно отправляется трафик в обоих направлениях, а достаточно только исходящего.
3. Возможно там есть лишние VLAN’ы с служебным трафиком, а Carbon Reductor анализирует только часть.
4. Если зеркал трафика несколько, можно балансировать отправку, указывая порты коммутатора, с которых оно снимается (в случае «перекосов»).

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

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

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

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

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

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

Flow-control

По умолчанию Carbon Reductor отключает flow-control для сетевых карт принимающих зеркало трафика, так как она чаще приводит к потерям, чем к сглаживанию пиковых нагрузок.

Проверить настройки можно с помощью команды:

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`:

I know this is a 1 year old question but it is 1st on Google so maybe I can add 5 cents to it.

First I was not aware of this mod 8 rule on frame field… Is it a driver rule or kernel rule?

In the little experience I have, these numbers are quite generic and more info can be obtained from ethtool (if the driver supports it) ex:
this is from watch command.

Every 1s: ethtool -S eth1 | grep rx_ && echo  && ifconfig eth1                                                   1970-01-01 00:21:07

 rx_octets: 12635134290
 rx_frames: 8488675
 rx_broadcast_frames: 103
 rx_multicast_frames: 0
 rx_pause_frames: 0
 rx_64_byte_frames: 113
 rx_65_127_byte_frames: 47
 rx_128_255_byte_frames: 186340
 rx_256_511_byte_frames: 1
 rx_512_1023_byte_frames: 0
 rx_1024_1518_byte_frames: 8302174
 rx_greater_than_1518_byte_frames: 0
 rx_undersized_frames: 0
 rx_oversize_frames: 0
 rx_jabbers: 0
 rx_frame_check_sequence_errors: 0
 rx_length_field_frame_errors: 0
 rx_symbol_errors: 0
 rx_alignment_errors: 0
 rx_resource_errors: 283
 rx_overruns: 132
 rx_ip_header_checksum_errors: 0
 rx_tcp_checksum_errors: 0
 rx_udp_checksum_errors: 0

eth1      Link encap:Ethernet  HWaddr AA:BB:CC:DD:20:16  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a8bb:ccff:fedd:2016/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8488675 errors:415 dropped:4 overruns:132 frame:283
          TX packets:647464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3892403548 (3.6 GiB)  TX bytes:62273943 (59.3 MiB)
          Interrupt:147 Base address:0xc000 

Depending on the driver there will be different fields in ethtool and
ifconfig fields can point to undersized/oversized frames as well.

If your NIC & driver supports it you can (or should) do ex:

ifdown eth1 && modprobe -r macb && modprobe macb && ifup eth1 && ethtool -offload  eth1  rx off  tx off && ethtool -K eth1 gso off && ethtool --show-offload eth1

in order to get more info (enable letting the info to be shown in ethtool). I’m using macb driver here… so check ethtool for your driver.

ethtool -i eth1

This is what helps me to understand usually what’s going on.

Sometimes there are no errors but packets are corrupted… then it is more of a PHYsical or driver problem… and sometimes sniffers show everything is correct but there is a problem after it gets to the driver/kernel (this is above’s case actually).

Some more can be obtained from netstat -s, or if you put this into a script (for small embedded systems):

awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} (f==1){ i=2; while ( i<=NF){ printf "%s = %dn", n[i], $i; i++}; f=0}'  /proc/net/netstat

since netstat -s might not be available.

RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать— пакеты приходящие к клиенту 

Типы ошибок:

CRC Error — ошибки проверки контрольной суммы

Undersize — возникают при получение фрейма размером 61-64 байта.

Фрейм передается дальше, на работу не влияет

Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой

Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме

Drop Pkts — пакеты отброшенные в одном из трех случаев:

Какие пакеты входят в Drop Packets при выводе show error ports?

Переполнение входного буфера на порту

Пакеты, отброшенные ACL

Проверка по VLAN на входе

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

Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.

Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред

Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета

Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается

Single Collision — единичная коллизия