... В производительность модуля фильтрация не упирается, как правило единственной проблемой при запуске бывает не совсем корректное работающее по умолчанию оборудование (процессор, сетевые карты). Мы много сталкивались с этим, поэтому готовы помочь с настройкой этого оборудования для обеспечения отличной производительности. Есть четыре вещи которые в основном влияют на потерю пакетов при приёме (допустим, нас не волнует как долго он будет проходить через нашу систему, то есть latency мы можем жертвовать), а наша задача - поймать все пакеты, не упустив ни одного и обработать. 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(). Итак, вещи: {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 ядер (довольно простой случай). Строка "-TxRx" - по ней можно идентифицировать очереди сетевой карты принимающей зеркало трафика, может отличаться в зависимости от модели сетевой карты и драйвера, посмотреть как она выглядит можно в файле cat /proc/interrupts {code} #!/bin/bash tune_nic() { echo "- Настраиваем прерывания $1" local nic="$1$2" local cpucount=$(grep -c 'model name' /proc/cpuinfo) grep $nic /proc/interrupts | while read irq $(eval echo cpu{1..$cpucount}) _ queue _; do irq=${irq//:} proc_entry=/proc/irq/$irq/smp_affinity_list evaled="${queue##*rx-}" echo $evaled > $proc_entry done } client_post_start_hook() { tune_nic "eth1" "-rx" tune_nic "eth2" "-TxRx" } {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. Отключение гипертрединга В некоторых случаях использование процессора с отключенным гипертредингом оказывалось эффективнее, чем с включенным, несмотря на меньшее количество логических ядер. Делать это стоит, если все предыдущие пункты не помогают.
|