... {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. Нагрузка на процессор и что она значит
Выполните команду
{code}
top -cd1
{code}
и нажмите клавишу "1".
Вы увидите что-то в духе:
{code}
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
{code}
Нас в основном интересуют цифры "%si".
# Нагрузка должна быть распределена равномерно, если Cpu0 трудится, а 1..n находятся на нуле - это не очень хорошо.
# 0% на каждом ядре - вы скорее всего ещё не настроили зеркало, а если всё работает - у вас замечательный сервер.
# 1-3% на каждом ядре - всё хорошо настроено, можно даже увеличивать канал и не особо беспокоиться об апгрейде железа.
# 6-10% в принципе сойдёт.
# 11-15% повод задуматься о покупке более хорошего оборудования или его настройке.
# 20-100% скорее всего будут потери пакетов и пропуски фильтрации. Если ситуация сохраняется после того, как вы прошлись по всем пунктам в этой статье (и воспользовались ими) - свяжитесь с технической поддержкой.
На постоянное использование можно добавлять команды в хук start.sh в функцию client_post_start_hook().
h1. Network Top
В комплекте с редуктором поставляется утилита
{code}
chroot /app/reductor network-top
{code}
Запускается без аргументов, показывает полную картину нагрузки на сетевые карты и ядра процессора в реальном времени. Аномально высокие значения подсвечиваются желтым (больше нормы) или красным (критично) цветом.
h1. Размер буфера сетевой карты
{code}
[root@centos ~]# 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}
Здесь мы видим увеличенный до максимума rx-буфер.
В Carbon Reductor DPI X при добавлении сетевой карты для фильтрации через мастер для неё автоматически настраивается оптимальный размер RX-буфера.
Также он настраивается автоматически при использовании опции FWBOOST.
h1. Распределение прерываний
{include:reductor5:Распределение прерываний}
h1. Мощность ядер процессора
В Carbon Reductor DPI X процессор автоматически настраивается на максимально доступную базовую частоту.
h1. Настройки rx-usecs
В Carbon Reductor DPI X автоматически подбирается оптимальное значение этого параметра для сетевой карты при использовании опций FWBOOST.
|
...
MTU на порту коммутатора, отправляющего зеркало не должно быть больше, чем MTU интерфейса на Carbon Reductor (в том числе и всех VLAN), принимающего зеркалированный трафик.
Рекомендуем посмотреть статистику на коммутаторе по распределению размеров пакетов, для D-Link например команда
{code}
show packet port 1:1
{code}
и вывод в духе:
{code}
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}
1519-2047 2321195608 1572
{code}
h2. Как определить потери пакетов из-за низкого MTU?
Посмотрите на RX: length значение.
{code}
# 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}
Как избавиться от этих потерь?
Разово:
{code}
ip link set eth1 mtu 1540
{code}
На постоянной основе:
Дописать в конфиг сетевой карты (например /etc/sysconfig/network-scripts/ifcfg-eth1):
{code}
MTU=1540
{code}
|
