... {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. net_rx_top
В комплекте с редуктором поставляется утилита
{code}
/usr/local/Reductor/bin/net_rx_top.sh
{code}
Запускается без аргументов, показывает прирост прерываний на одно ядро процессора в секунду. Рекомендуемое число: меньше 20000 на ядро.
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-буфер. Обычно подобрать значение довольно сложновато, ибо тут такая ситуация - либо задержки (плохо для скорости реакции на пакет), либо потери (плохо, что нужный ip-пакет вообще не попадёт на анализ). Самое оптимальное - некоторое "среднее" значение. При высокочастотном и многоядерном процессоре (>3ГГц) можно ближе к максимуму/максимальный буфер. Пример команды для увеличения буфера:
{code}
ethtool -G eth1 rx 2048
{code}
CentOS позволяет указывать параметры ethtool в качестве опции в настройках интерфейса (/etc/sysconfig/network-scripts/ifcfg-eth1), например строчкой
{code}
ETHTOOL_OPTS="-G ${DEVICE} rx 2048"
{code}
К сожалению он не позволяет указывать несколько команд одновременно, но можно добавить их в хук.
|
...
{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
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
Статья для лучшего понимания, правда больше под маршрутизаторы : [http://habrahabr.ru/post/108240/]
В кратце - можно за счёт повышения нагрузки на процессор слегка снять нагрузку с сетёвки уменьшая rx-usecs. На большинстве машин использумых в нашем случае оптимальным оказалось значение 1.
{code}
ethtool -C eth1 rx-usecs 1
{code}
h1. Замена сетевых карт
Иногда бывает дело просто в железе. Если уверены, что сетевая карта хорошей модели и есть ещё одна такая же - попробуйте использовать её. Возможно она просто бракованная, хоть вероятность и мала.
Иногда дело бывает в драйвере (в случае dlink / realtek сетевых карт). Они, конечно, здорово поддерживаются практически любым дистрибутивом, но для высоких нагрузок не очень подходят.
h1. Отключение гипертрединга
В некоторых случаях использование процессора с отключенным гипертредингом оказывалось эффективнее, чем с включенным, несмотря на меньшее количество логических ядер.
Делать это стоит, если все предыдущие пункты не помогают.
h1. NOTRACK
Если вы уверенны в отсутствии петель в зеркале (в Carbon Reductor не попадает его собственный трафик, можно проверить это с помощью tcpdump), то можно поэкспериментировать с этой опцией. Если в течение пары-тройки часов после включения проблем с выгрузкой и работой сети на Carbon Reductor не возникло, то её можно использовать. Она применяет ко всем пакетам идущим на интерфейсы во всех бриджах правило с \-j NOTRACK, что приводит к значительному снижению нагрузки на процессор.
Можно с tcpdump на интерфейсах в бридже послушать:
{code}
tcpdump -nneei <сетёвка в зеркале> -с 100 host <ip с которого редуктор в инет ходит и редиректы шлёт>
{code}
в другом окне ssh при этом
{code}
curl ya.ru
nslookup google.com
{code}
если ни в одном из интерфейсов куда зеркало валится таких пакетов нет, то можно включать 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
{code}
ПОСЛЕ включения:
{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}
h1. Включение RPS (актуально для realtek/dlink/бюджетных intel)
Примечание - включать надо для всех vlan на сетевой карте отдельно. Включение только для самого девайса ethX не снизит нагрузку, создаваемую обработкой пакетов с vlan-интерфейсов.
Мы в скором времени постараемся сделать автоматическую настройку при необходимости.
Пока можно включить руками или добавив в хук команду в духе:
{code}
cpucount="$(grep -c 'model name' /proc/cpuinfo)"
printf "%x\n" $((2**cpucount-1)) > /sys/class/net/eth1/queues/rx-0/rps_cpus
{code}
h1. Актуализация настроек зеркала трафика
Разнесение всех интерфейсов зеркала трафика по отдельным бриджам даёт небольшое снижение нагрузки за счёт устранения небольшой петли.
h1. Использование нескольких сетевых карт для приёма зеркала
Вы можете раскидать зеркало между несколькими сетевыми картами, указав в настройках создаваемых зеркал равные диапазоны абонентских портов.
h1. Отключение логирования
menu > настройки алгоритма фильтрации > логировать срабатывания
отключите эту опцию, это _немного_ ускорит процесс обработки пакета и отправки редиректа. Однако несмотря на "немного", при очень частых срабатываниях - способно даже немного снизить нагрузку на процессор.
h1. MTU
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}
|
