В производительность модуля фильтрация не упирается, как правило единственной проблемой при запуске бывает не совсем корректное работающее по умолчанию оборудование (процессор, сетевые карты). Мы много сталкивались с этим, поэтому готовы помочь с настройкой этого оборудования для обеспечения отличной производительности.
Есть четыре вещи которые в основном влияют на потерю пакетов при приёме (допустим, нас не волнует как долго он будет проходить через нашу систему, то есть latency мы можем жертвовать), а наша задача - поймать все пакеты, не упустив ни одного и обработать.
На постоянное использование можно добавлять команды в хук start.sh в функцию client_post_start_hook().
Итак, вещи:
{toc}
Разберём их по порядку:
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-буфер. Обычно подобрать значение довольно сложновато, ибо тут такая ситуация - либо задержки, либо потери, но нас задержки не волнуют, так как редуктор стоит сбоку от основного потока трафика, так что выкручиваем буфер на максимум. Пример команды для увеличения буфера.
{code}
ethtool -G eth1 rx 4096
{code}
CentOS позволяет указывать параметры ethtool в качестве опции в настройках интерфейса (/etc/sysconfig/network-scripts/ifcfg-eth1), например строчкой
{code}
ETHTOOL_OPTS='-G eth1 rx 4096'
{code}
К сожалению он не позволяет указывать несколько команд одновременно, но можно добавить их в хук.
h1. Распределение прерываний
Многие сетевые карты имеют несколько очередей для входящих пакетов. Каждая очередь висит на ядре/списке ядер. На многих железках из коробки, несмотря на то, что в smp_affinity_list указан список 0-$cpucount все прерывания находятся на первом ядре процессора. Обойти это можно раскидав с помощью echo все прерывания на разные ядра.
По возможности используйте разные реальные ядра, допустим, дано:
- 1 процессор с гипертредингом
- 4 реальных ядра
- 8 виртуальных ядер
- 4 очереди сетевой карты, которые составляют 95% работы сервера
Раскинуть их на 0, 1, 2 и 3 ядра будет не так эффективно, как на 0, 2, 4 и 6.
Пример кода (костыльный и неуниверсальный), который раскидывает 8 очередей на 8 ядер (довольно простой случай).
Строка "eth1-TxRx-" - по ней можно идентифицировать очереди сетевой карты принимающей зеркало трафика, может отличаться в зависимости от модели сетевой карты и драйвера, посмотреть как она выглядит можно в файле cat /proc/interrupts
{code}
#!/bin/bash
nic=eth1-TxRx-
cpucount=$(grep -c 'model name' /proc/cpuinfo)
grep $nic /proc/interrupts | while read irq $(eval echo cpu{1..$cpucount}) t queue t; do
irq=${irq//:/}
/proc/irq/$irq/smp_affinity_list
echo "${queue##*TxRx-}" > /proc/irq/$irq/smp_affinity_list
done
{code}
h1. Мощность ядер процессора
{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, что приводит к значительному снижению нагрузки на процессор.
h1. Актуализация настроек зеркала трафика
Разнесение всех интерфейсов зеркала трафика по отдельным бриджам даёт небольшое снижение нагрузки за счёт устранения небольшой петли.
Есть четыре вещи которые в основном влияют на потерю пакетов при приёме (допустим, нас не волнует как долго он будет проходить через нашу систему, то есть latency мы можем жертвовать), а наша задача - поймать все пакеты, не упустив ни одного и обработать.
На постоянное использование можно добавлять команды в хук start.sh в функцию client_post_start_hook().
Итак, вещи:
{toc}
Разберём их по порядку:
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-буфер. Обычно подобрать значение довольно сложновато, ибо тут такая ситуация - либо задержки, либо потери, но нас задержки не волнуют, так как редуктор стоит сбоку от основного потока трафика, так что выкручиваем буфер на максимум. Пример команды для увеличения буфера.
{code}
ethtool -G eth1 rx 4096
{code}
CentOS позволяет указывать параметры ethtool в качестве опции в настройках интерфейса (/etc/sysconfig/network-scripts/ifcfg-eth1), например строчкой
{code}
ETHTOOL_OPTS='-G eth1 rx 4096'
{code}
К сожалению он не позволяет указывать несколько команд одновременно, но можно добавить их в хук.
h1. Распределение прерываний
Многие сетевые карты имеют несколько очередей для входящих пакетов. Каждая очередь висит на ядре/списке ядер. На многих железках из коробки, несмотря на то, что в smp_affinity_list указан список 0-$cpucount все прерывания находятся на первом ядре процессора. Обойти это можно раскидав с помощью echo все прерывания на разные ядра.
По возможности используйте разные реальные ядра, допустим, дано:
- 1 процессор с гипертредингом
- 4 реальных ядра
- 8 виртуальных ядер
- 4 очереди сетевой карты, которые составляют 95% работы сервера
Раскинуть их на 0, 1, 2 и 3 ядра будет не так эффективно, как на 0, 2, 4 и 6.
Пример кода (костыльный и неуниверсальный), который раскидывает 8 очередей на 8 ядер (довольно простой случай).
Строка "eth1-TxRx-" - по ней можно идентифицировать очереди сетевой карты принимающей зеркало трафика, может отличаться в зависимости от модели сетевой карты и драйвера, посмотреть как она выглядит можно в файле cat /proc/interrupts
{code}
#!/bin/bash
nic=eth1-TxRx-
cpucount=$(grep -c 'model name' /proc/cpuinfo)
grep $nic /proc/interrupts | while read irq $(eval echo cpu{1..$cpucount}) t queue t; do
irq=${irq//:/}
/proc/irq/$irq/smp_affinity_list
echo "${queue##*TxRx-}" > /proc/irq/$irq/smp_affinity_list
done
{code}
h1. Мощность ядер процессора
{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, что приводит к значительному снижению нагрузки на процессор.
h1. Актуализация настроек зеркала трафика
Разнесение всех интерфейсов зеркала трафика по отдельным бриджам даёт небольшое снижение нагрузки за счёт устранения небольшой петли.