LINUX.ORG.RU
ФорумAdmin

intel i350 перегрузка CPU при 450 мегабитах


1

1

Доброго дня!
Стоит в сервере внешняя 4-х портовая сетевень i350
При 400 мегабитах top говорит:


Cpu0  :  8.0%us,  0.0%sy,  0.0%ni, 13.4%id,  0.0%wa,  0.0%hi, 78.6%si,  0.0%st
Cpu1  :  4.0%us,  0.0%sy,  0.0%ni, 18.4%id,  0.0%wa,  0.0%hi, 77.6%si,  0.0%st
Cpu2  :  0.7%us,  0.0%sy,  0.0%ni, 18.0%id,  0.0%wa,  0.0%hi, 81.3%si,  0.0%st
Cpu3  :  3.3%us,  0.3%sy,  0.0%ni, 20.1%id,  0.0%wa,  0.0%hi, 76.3%si,  0.0%st
Cpu4  :  4.0%us,  0.3%sy,  0.0%ni, 17.3%id,  0.0%wa,  0.0%hi, 78.4%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni, 20.7%id,  0.0%wa,  0.0%hi, 79.3%si,  0.0%st
Cpu6  :  2.0%us,  0.3%sy,  0.0%ni, 19.9%id,  0.0%wa,  0.0%hi, 77.7%si,  0.0%st
Cpu7  :  0.7%us,  0.3%sy,  0.0%ni, 14.1%id,  0.0%wa,  0.0%hi, 84.9%si,  0.0%sе


Как видно si - soft interrupts в среднем 80%

Работает под последним 4.12 рекомендованным драйвером igb с параметрами:

[br]options igb IntMode=2,2,2,2 RSS=8,8,8,8 QueuePairs=0,0,0,0 InterruptThrottleRate=4000,4000,4000,4000[br]

tx-rx очереди объединены. Отдельные очереди эффекта не дали. Сейчас по 8 очередей на интерфейс, по паре очередей повешено на каждое ядро типа tx-rx0/tx-rx7 tx-rx1/tx-rx6
sysctl.conf
net.netfilter.nf_conntrack_max=5242880
net.ipv4.neigh.default.gc_thresh3=4096
net.ipv4.neigh.default.gc_stale_time=240
net.ipv4.tcp_syn_retries=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.neigh.default.gc_thresh1=1280
net.core.netdev_max_backlog=2048000
net.ipv4.conf.default.rp_filter=1
net.ipv4.ip_dynaddr=1
net.ipv4.tcp_max_tw_buckets=1440000
net.ipv4.tcp_moderate_rcvbuf=1
net.core.somaxconn=26214400
kernel.panic=10
net.ipv4.tcp_orphan_retries=1
net.ipv4.tcp_syncookies=1
net.ipv4.ip_forward=1
net.ipv4.tcp_synack_retries=1
net.nf_conntrack_max=5242880
net.ipv4.tcp_window_scaling=0
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.ipv4.tcp_rmem = 8192 8388608 16777216
net.ipv4.tcp_wmem = 8192 4194394 16777216
net.core.wmem_default = 4194394
net.core.rmem_default = 8388608
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_keepalive_intvl=15
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_sack=0
net.ipv4.neigh.default.gc_thresh2=2048


Ядро Linux gw2 2.6.35.106.i686.PAE

Больше 500 мегабит маршрутизатор реально не пропускает. На сервере поднят BGP OSPF и он также натит всё, что касается серых адресов.

Подскажите, куда копать - загруку CPU убрать и как следствие вернуть пропускную способность?
Я уже склоняюсь к мысли преустановить всё к чертям... на 3.8 ядро, дистриб там сейчас староват...



Последнее исправление: gich (всего исправлений: 5)
Ответ на: комментарий от gich

У них это называется interrupt throttle - попробуй изменять его в ту или иную сторону (у тебя именно обработка прерываний съедает время). Еще можно попробовать включить jumbo frames.

tailgunner ★★★★★
()
Ответ на: комментарий от gich

Если и настройки throttle rate ни на что не повлияют, то одно из двух: либо у тебя настройки не применяются, либо проблема не в карте и не в ее драйвере, так что нужно профилировать систему.

tailgunner ★★★★★
()
For example, with two Gigabit PCI adapters, entering:

    modprobe igb TxDescriptors=80,128

попробуй RxDescriptors=1024,1024,1024,1024 и TxDescriptors=1024,1024,1024,1024

или сколько там можно, лень смотреть в драйвер

InterruptThrottleRate=2000,2000,2000,2000

поставь ethtool и посмотри включен ли всякий tcp offload и прочее на интерфейсах.

dimon555 ★★★★★
()

А какое железо то? И почему 32-битное ядро? Драйвер igb внеядерный?

У меня даже 10Гбит карты прокачивают на полную без особых проблем на не самом новом Nehalem при разнесенных прерываниях.

И вообще, если это роутер, то может не в мегабитах дело, а в PPS? Тогда 500Мбит это еще неплохо :)

Помучай его iperf-ом, тогда будет ясно.

blind_oracle ★★★★★
()
Ответ на: комментарий от hizel

Затем, чтобы понять где проблема. Если гонять айперфом, то пакеты будут равны MTU, а не хрен знает чему. Если и при айперфе будет тупить, то проблем не в траффике.

blind_oracle ★★★★★
()

1. Если сервер занимается только транзитом IP пакетов то для чего nf_conn_track ? остановите iptables, легчает?
2. у драйверов igb InterruptThrottleRate по умолчанию 3=dynamic conservative, т.е. драйвер сам регулирует число прерываний.
3. IntMode по умолчанию = 2 (MSI-X) 4. Что говорит sar -I SUM -n DEV 1 во время 80% загрузки si? какое соотношение числа пропущенных пакетов и прерываний процессора?
5. Тема загрузки раскрывается также вот здесь http://forum.nag.ru/forum/index.php?showtopic=46335

Vlad-76 ★★★★
()
Ответ на: комментарий от dimon555

поставь ethtool

Вот такой результат:
ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: on

Пробовал InterruptThrottleRate в разных сочетаниях. 1-3, 100, 1000, 10000, RxDescriptors - ни какой разницы.

И вообще, если это роутер, то может не в мегабитах дело, а в PPS? Сейчас значение 50000 где-то + -. Даже для роутера это не много.

....вот почитай, что люди делают...

По CPU развешаны прерывания были в первую очередь.



Чувствую, дело пахнет всё сильнее переустановкой оси...

gich
() автор топика
Ответ на: комментарий от hizel

Я, впрочем, при таком трафике уже бы разделил, вынес бы бордер отдельно и nat тоже

Бордер то как раз, на сколько я знаю не много жрёт ресурсов, в соотношении с NAT 9/1. Или я глубоко заблуждаюсь?

gich
() автор топика
Ответ на: комментарий от gich

есть сервер с двумя Xeon E5345 + двухпортовая 82576, занимается только транзитом трафика, в чнн PPS 65к вход+исход. Максимальная загрузка по одному из загруженных ядер не превышает 0,8%.
igb гружу с параметрами RSS=8,8
Цифры ядра 2.6.35 точно такие же
ethtool показывает аналогичную картину
oprofile покажет картину кто сжирает проц.

Vlad-76 ★★★★
()

Покажите правила iptables и tc. 400 мегабит делает даже целерон с реалтеком, без тюнинга. Скорее всего у вас правила файрволла ужастно написаны.

ventilator ★★★
()

Кроме того почти весь ваш тюнинг в sysctl.conf для роутера вообще ничего не дает. Менять в принципе есть смысл только nf_conntrack_max,netdev_max_backlog,nf_conntrack_buckets.

nf_conntrack_buckets часто нужно указывать в /etc/modules:

nf_conntrack hashsize=1048576

Покажите так же значение net.netfilter.nf_conntrack_count.

ventilator ★★★
()
Ответ на: комментарий от tailgunner

(у тебя именно обработка прерываний съедает время)

si - это не именно обработка прерываний. Все процессорное время которое уходит на обработку пакета ядром(правила файрвола, роутинг, нат, шейпинг) будет засчитано как si.

ventilator ★★★
()
Ответ на: комментарий от ventilator

si - это не именно обработка прерываний

Это отложенное прерывание. Происходить в нем может много чего, поэтому я сказал «надо профилировать».

tailgunner ★★★★★
()
Ответ на: комментарий от ventilator

настройки interrupt coalescing обычно никак не влияют на si.

Если в si выполняется много работы помимо обслуживания прерывания.

tailgunner ★★★★★
()
Ответ на: комментарий от blind_oracle

%si это программные прерывания, softirq, а interrupt coalesce влияет на железные прерывания, %hi

В зависимости от того, как написан драйвер, каждое hi может сопровождаться si.

tailgunner ★★★★★
()
Ответ на: комментарий от hizel

Я, впрочем, при таком трафике уже бы разделил, вынес бы бордер отдельно и nat тоже, например.

При каком таком? Гигабит натится/маршрутизируется/шейпится практически любой железякой из нынешнего века не нагибаясь на тыщу-другую клиентов. Другое дело, если там аномальное количество пакетов при этом.

madcore ★★★★★
()
Ответ на: комментарий от vel

ip ro | wc -l говорит 447783, оно же full view

Покажите так же значение nf_conntrack_count

net.netfilter.nf_conntrack_count = 202224

Скорее всего у вас правила файрволла ужастно написаны

Сомневаюсь. Я пробовал на время теста всем INPUT OUTPUT FORWARD поставить 1 по счёту правило -j ACCEPT, mangle был сброшен полностью, nat PREROUTING -j ACCEPT первым по счёту,
в nat POSTROUTING там минимальный набор из 10 правил для нашей сетки. Пробовал теста ради там вообще всё свести до SNAT серых адресов - не играет роли никакой. Шейпинг вынесен на отдельный север. С ним проблем нет.

gich
() автор топика
Ответ на: комментарий от madcore

я говорю о масштабировании, впрочем, котик, расскажи мне больше о своем pps.

hizel ★★★★★
()
Ответ на: комментарий от gich

Путём танцев с бубном во время зависания практически системы было сделано следующее:

cat igb.conf
options igb IntMode=2,2,2,2 RSS=4,4,4,4 QueuePairs=0,0,0,0 InterruptThrottleRate=1,1,1,1

Получено таким образом по 4rx-4tx очереди. Развесил это дело по прерываниям таким образом:
[code]
141: 0 0 0 0 0 0 1 0 PCI-MSI-edge eth1
142: 44683331 0 0 0 0 0 0 542963 PCI-MSI-edge eth1-rx-0
143: 0 8731 0 592738 38210070 0 0 0 PCI-MSI-edge eth1-rx-1
144: 392759 4307 41611507 0 0 0 0 0 PCI-MSI-edge eth1-rx-2
145: 0 0 4542 0 587053 0 34723061 0 PCI-MSI-edge eth1-rx-3
146: 430578 104543640 9460 0 0 0 0 0 PCI-MSI-edge eth1-tx-0
147: 0 0 7127 0 0 85847325 661928 0 PCI-MSI-edge eth1-tx-1
148: 571141 0 7572 98879439 0 0 0 0 PCI-MSI-edge eth1-tx-2
149: 0 0 1035724 6772 0 0 0 92074626 PCI-MSI-edge eth1-tx-3
150: 0 0 0 1 0 0 0 0 PCI-MSI-edge eth0
151: 418082 0 0 6827 0 0 0 81709690 PCI-MSI-edge eth0-rx-0
152: 460494 0 0 83824910 6547 0 0 0 PCI-MSI-edge eth0-rx-1
153: 0 0 0 0 6941 76609776 0 0 PCI-MSI-edge eth0-rx-2
154: 0 88573914 0 0 6566 0 0 0 PCI-MSI-edge eth0-rx-3
155: 0 0 0 0 3248 577571 35839968 0 PCI-MSI-edge eth0-tx-0
156: 0 618170 42477525 0 0 4083 0 0 PCI-MSI-edge eth0-tx-1
157: 0 0 0 0 39954095 3008 0 0 PCI-MSI-edge eth0-tx-2
158: 45858053 0 0 0 0 3072 0 0 PCI-MSI-edge eth0-tx-3
[/code]
[code]
cat ethirq5.sh
#CPU0
echo 1 > /proc/irq/141/smp_affinity
echo 1 > /proc/irq/150/smp_affinity

echo 1 > /proc/irq/142/smp_affinity
echo 1 > /proc/irq/158/smp_affinity

#CPU1
echo 2 > /proc/irq/146/smp_affinity
echo 2 > /proc/irq/154/smp_affinity

#CPU2
echo 4 > /proc/irq/144/smp_affinity
echo 4 > /proc/irq/156/smp_affinity

#CPU3
echo 8 > /proc/irq/148/smp_affinity
echo 8 > /proc/irq/152/smp_affinity

#CPU4
echo 10 > /proc/irq/143/smp_affinity
echo 10 > /proc/irq/157/smp_affinity

#CPU5
echo 20 > /proc/irq/147/smp_affinity
echo 20 > /proc/irq/153/smp_affinity

#CPU6
echo 40 > /proc/irq/145/smp_affinity
echo 40 > /proc/irq/155/smp_affinity

#CPU7
echo 80 > /proc/irq/149/smp_affinity
echo 80 > /proc/irq/151/smp_affinity
[/code]

Система прожевала 560. CPU %si=80 в среднем. Но не мегабита больше. Хотя должна бы.
Пакетов не аномальное количество 65000pps где-то было.

gich
() автор топика
Ответ на: комментарий от gich

1.Из описания к драйверу
IntMode
-------
Valid Range: 0 - 2 (0 = Legacy Int, 1 = MSI and 2 = MSI-X)
Default Value: 2
Зачем указывать дефолтное значение параметра при загрузке модуля?
2. Очереди необходимо сделать сдвоенные, выглядеть они должны как
eth2-TxRx-0
eth2-TxRx-1
eth2-TxRx-2
Число строк скрипта развешивающего прерывания по ядрам уменьшится вдвое.
3. http://www.intel.com/content/dam/doc/application-note/gbe-controllers-interru...
В документе говорят, что объединение в bonding двух интерфейсов приведет к снижению числа прерываний

Vlad-76 ★★★★
()
Ответ на: комментарий от gich

Собственно это я и хотел увидить - full view

Нужно искать статейки про настройку маршрутизаторов с длинными таблицами маршрутизации. Я практически уверен, что если в вашем варианте убрать full view, то скорость возрастет. Есть смысл оценить эффективность кеша маршрутизации

«lnstat -s1 -i1 -c-1 -f rt_cache»

Некоторые настройки описаны в http://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux.html

Я бы попытался разделить эту систему на 2 части (средствами lxc)

1) bgp router без NAT & conntrack c минимальным iptables

2) NAT + все остальное.

vel ★★★★★
()
Ответ на: комментарий от gich

Сомневаюсь. Я пробовал на время теста всем INPUT OUTPUT FORWARD поставить 1 по счёту правило -j ACCEPT, mangle был сброшен полностью, nat PREROUTING -j ACCEPT первым по счёту,
в nat POSTROUTING там минимальный набор из 10 правил для нашей сетки. Пробовал теста ради там вообще всё свести до SNAT серых адресов - не играет роли никакой. Шейпинг вынесен на отдельный север. С ним проблем нет.

Вы правила-то покажите. И nf_conntrack_buckets.

ventilator ★★★
()
Последнее исправление: ventilator (всего исправлений: 1)
Ответ на: комментарий от vel

Нужно искать статейки про настройку маршрутизаторов с длинными таблицами маршрутизации. Я практически уверен, что если в вашем варианте убрать full view, то скорость возрастет. Есть смысл оценить эффективность кеша маршрутизации

На старых ядрах единственная настройка при сборке ядра - хранить роут таблицу как LC_TRIE вместо обычного хеша. Но не изменение этого параметра не может дать такую деградацию роизводительности. Еще кстати PAE ядро - неудачный выбор.

ventilator ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.