[pchol]

Добрый день.

Сложилась такая ситуация. Вечерами, при повышении активности пользователей замечена более медленная работа инета.

Медленность характеризуется задержками при сёрфинге на 2-3 секунды перед открытием страницы, и не зависимо от браузера и сайта. И периодически подскакивающими пингами (увеличиваются в 20-30 раз), на небольшой промежуток времени (5-10 сек), даже при пустом канале пользователя.

Однако различные спидтесты показывают нормальные отклики и нормальные скорости upload/download.

Ищу причину этого безобразия...

На сервере крутится nat + шейпер.

Шейпер htb представляет собой 1 родительский и 3к дочерних классов так сказать "паралельных", то есть ветвления нет.

NAT, порядка 70 статичных записей snat /dnat для проброса белых адресов + 1 общая запись SNAT "на всех остальных"

Порядка 350 статичных записей в таблице filter на дроп пакетов от клиентов которым запрещён доступ.

"Замедление" работы начинается при примерно вот такой нагрузке

shaper:~# ethstats
total:   143.07 Mb/s In   139.55 Mb/s Out -  27547.0 p/s In   27047.0 p/s Out
  eth2:   86.82 Mb/s In    56.13 Mb/s Out -  14228.0 p/s In   13458.0 p/s Out
  eth3:   56.25 Mb/s In    83.43 Mb/s Out -  13319.0 p/s In   13589.0 p/s Out

 

Если поглядеть на число записей в таблице коннтрака, вроде бы всё нормально.

shaper:~# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
60194

 

Процессоры в принцие не нагружены

shaper:~# mpstat -P ALL 1
Linux 2.6.31.4 (shaper)         31.10.2009      _x86_64_

21:30:49     CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
21:30:50     all    0,00    0,00    0,00    0,00    0,25    6,89    0,00   92,86  42576,00
21:30:50       0    0,00    0,00    0,00    0,00    0,95    8,57    0,00   90,48   1650,00
21:30:50       1    0,00    0,00    0,00    0,00    0,00    7,00    0,00   93,00   1650,00
21:30:50       2    0,00    0,00    0,00    0,00    0,00   11,58    0,00   88,42   1651,00
21:30:50       3    0,00    0,00    0,00    0,00    0,00    6,00    0,00   94,00   1651,00
21:30:50       4    0,00    0,00    0,00    0,00    0,00    2,86    0,00   97,14   1651,00
21:30:50       5    0,00    0,00    0,00    0,00    0,00    7,53    0,00   92,47   1651,00
21:30:50       6    0,00    0,00    1,02    0,00    0,00    4,08    0,00   94,90   1650,00
21:30:50       7    0,00    0,00    0,00    0,00    0,00    8,00    0,00   92,00   1650,00

 

Прерывания распихиваются вроде бы нормально.

shaper:~# cat /proc/interrupts | grep eth
56:  121995398  121899102  121915565  121897152  122404638  121856906  122441825  121908825   PCI-MSI-edge      eth2
57:  282993817  282758347  283110630  282768854  282236610  283029122  282137391  282877789   PCI-MSI-edge      eth3

 

ksoftirqd всё же отжирает проессорное время.

shaper:~# top -b | grep ksoftirqd
   10 root      15  -5     0    0    0 S    2  0.0  40:04.88 ksoftirqd/2
    4 root      15  -5     0    0    0 S    0  0.0  45:10.02 ksoftirqd/0
    7 root      15  -5     0    0    0 S    0  0.0  44:03.98 ksoftirqd/1
   13 root      15  -5     0    0    0 S    0  0.0  39:40.28 ksoftirqd/3
   16 root      15  -5     0    0    0 S    0  0.0  39:46.73 ksoftirqd/4
   19 root      15  -5     0    0    0 S    0  0.0  39:29.74 ksoftirqd/5
   22 root      15  -5     0    0    0 S    0  0.0  40:24.10 ksoftirqd/6
   25 root      15  -5     0    0    0 S    0  0.0  39:42.61 ksoftirqd/7

shaper:~# uptime
21:31:46 up 3 days, 12:12,  2 users,  load average: 0.00, 0.00, 0.00

 

 

Запустил oproreport получил вот такую картинку

 2510328 84.2717 vmlinux
   194686  6.5356 processor
   145597  4.8877 e1000e
    98869  3.3190 ip_tables
     8467  0.2842 oprofiled
     6793  0.2280 nf_nat
     4939  0.1658 iptable_nat
     2908  0.0976 nf_conntrack_ipv4
     1947  0.0654 oprofile
      843  0.0283 libc-2.7.so
      815  0.0274 bash
      656  0.0220 iptable_mangle
      652  0.0219 iptable_filter
      304  0.0102 ld-2.7.so
      217  0.0073 nf_defrag_ipv4
      197  0.0066 ext3
      197  0.0066 jbd
      185  0.0062 nf_conntrack_netlink
       27 9.1e-04 libata

 

Сетевухи intel 82571EB.

 

На что грешить и куда рыть ?

У меня единственное предположение на iptables, ибо он собран монолитом в ядре, практически со всеми опциями.

Может быть подскажите как решить проблему ? Буду очень признателен.

Изменено 31 октября, 2009 пользователем pchol

[_dmitr_]

а polling есть какойнить?вообще проц как првило не играет решающей роли в скорости работы маршрутизатора, роль играет память, оперативная, ибо все процессы происходят в ней.

[pchol]

А может точнее подскажите что нужно показать /посмотреть ?

shaper:~# vmstat -s
      4054716 K total memory
      1313176 K used memory
       671844 K active memory
       317352 K inactive memory
      2741540 K free memory
       176756 K buffer memory
       799004 K swap cache
      4000144 K total swap
            0 K used swap
      4000144 K free swap
       241145 non-nice user cpu ticks
            0 nice user cpu ticks
       271570 system cpu ticks
    234956401 idle cpu ticks
         5652 IO-wait cpu ticks
       508892 IRQ cpu ticks
     12810542 softirq cpu ticks
            0 stolen cpu ticks
       300415 pages paged in
      2091784 pages paged out
            0 pages swapped in
            0 pages swapped out
   1051559695 interrupts
    439187455 CPU context switches
   1256710764 boot time
       483923 forks

Или вы имели ввиду NAPI ? Оно включено вроде как...

Изменено 31 октября, 2009 пользователем pchol

[nuclearcat]

Судя по oprofile и mpstat - узких мест нет.

Скорее всего неправильная конфигурация шейпера.

[pchol]

3к статичных параллельных классов не есть гуд....

сам понимаю...

но какие варианты решения ?

[photon]

Классов может быть сколько угодно (от 1 до ffff). Главное использовать эффективные фильтры (u32 hashing filters или flow), чтобы пакеты не проходили по сотням правил.

Изменено 1 ноября, 2009 пользователем photon

[pchol]

Делается вот так на каждого клиента.

#192.168.41.24
/sbin/tc class add dev eth3 parent 1:1 classid 1:216 htb rate 256kbit ceil 256kbit prio 0
/sbin/tc filter add dev eth3 protocol ip parent 1:0 prio 4 u32 match ip dst 192.168.41.24/32 flowid 1:216

 

[vitalyb]

pchol

 

ethtool -S eth2

ethtool -S eth3

 

Прерывания распихиваются вроде бы нормально

Они не "распихиваются", "прибейте" два рабочих интерфейса к ядрам с общим L2 кешем - будет проще смотреть загрузку и эффективней будут работать кеши CPU.

 

Скорее всего вам давно пора оптимизировать правила iptables (ipset) и обязательно использовать хеширование в tc.

 

[pchol]

shaper:~# ethtool -S eth2
NIC statistics:
     rx_packets: 3592820427
     tx_packets: 3554837070
     rx_bytes: 2800779148501
     tx_bytes: 2014683225916
     rx_broadcast: 1631415
     tx_broadcast: 88910
     rx_multicast: 0
     tx_multicast: 6
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 0
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 25783
     rx_missed_errors: 7242
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 1054
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 386
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 2800779148501
     rx_csum_offload_good: 3571322088
     rx_csum_offload_errors: 128828
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 5486
     rx_smbus: 3305766
     dropped_smbus: 257
     rx_dma_failed: 0
     tx_dma_failed: 0

shaper:~# ethtool -S eth3
NIC statistics:
     rx_packets: 3431705147
     tx_packets: 3430207000
     rx_bytes: 2006615481299
     tx_bytes: 2781607865853
     rx_broadcast: 31582127
     tx_broadcast: 2529546
     rx_multicast: 27198
     tx_multicast: 8
     rx_errors: 29
     tx_errors: 0
     tx_dropped: 0
     multicast: 27198
     collisions: 0
     rx_length_errors: 29
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 36453
     rx_missed_errors: 10170
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 30
     rx_long_length_errors: 29
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 3485
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 2006615481299
     rx_csum_offload_good: 3373117995
     rx_csum_offload_errors: 6928
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 5487
     rx_smbus: 31847346
     dropped_smbus: 11230
     rx_dma_failed: 0
     tx_dma_failed: 0

 

Попадания в те 350 правил на дроп практически нулевые.

Изменено 1 ноября, 2009 пользователем pchol

[pchol]

Сделал...

 

shaper:~# cat /proc/interrupts | grep eth
56:  144908488  144821762  144826108  144794095  145291278  144664921  145327916  144713586   PCI-MSI-edge      eth2
57:  329576132  329267864  329702266  329319354  328876822  329790858  328779315  329620048   PCI-MSI-edge      eth3

 

ждём минуту и делаем снова, видим

shaper:~# cat /proc/interrupts | grep eth
56:  145021168  144935107  144939637  144907026  145291278  144664921  145327916  144713586   PCI-MSI-edge      eth2
57:  329576132  329267864  329702266  329319354  329205858  330119714  329108269  329948866   PCI-MSI-edge      eth3

 

Вроде всё так да ? eth2 на одном проце, eth3 на втором...

 

зато теперь видим вот такую картинку:

mpstat -P ALL 1
12:25:58     CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
12:25:59     all    0,00    0,00    0,24    0,00    0,37    5,13    0,00   94,25  19004,00
12:25:59       0    0,00    0,00    1,00    0,00    1,00   11,00    0,00   87,00   1170,00
12:25:59       1    0,00    0,00    1,03    0,00    0,00    9,28    0,00   89,69   1170,00
12:25:59       2    0,00    0,00    0,00    0,00    0,00   11,46    0,00   88,54   1170,00
12:25:59       3    0,00    0,00    0,00    0,00    0,00   10,31    0,00   89,69   1170,00
12:25:59       4    0,00    0,00    0,00    0,00    1,01    0,00    0,00   98,99   2573,00
12:25:59       5    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00   2573,00
12:25:59       6    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00   2573,00
12:25:59       7    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00   2574,00

 

а ksoftirqd относительно второго проца вообще стоят на месте.

Изменено 1 ноября, 2009 пользователем pchol

[photon]

А хэширование в tc вы уже сделали? Если да, то действительно все из-за правил iptables.

Изменено 1 ноября, 2009 пользователем photon

[pchol]

Нет, займусь тогда им...

Изменено 1 ноября, 2009 пользователем pchol

[vitalyb]

Попадания в те 350 правил на дроп практически нулевые

Важно не столько попадание, сколько наличние самой проверки. Если у Вас 350 правил "не попадают", а потом одно посли них "попадает" - на каждый пакет всеравно приходится куча лишних действий.

 

Вроде всё так да ? eth2 на одном проце, eth3 на втором...

Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность).

 

[pchol]

Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность).

Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ?

[Ivan_83]

А пакеты у вас по дороге не бьются?

[vitalyb]

Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ?

На свежих ядрах можно посмотреть в /sys/devices/system/cpu/

[pchol]

Небольшой отчёт...

Разнёс прерывания от сетевух на 4 ядра (2 на одном процессоре физическом, 2 на другом), в результате ksoftirqd замер на месте и двигается только иногда во время пиковых нагрузок.

Сделал хеширование в tc, значительно ускорилась работа.

Отказался от ipset и iptables для дропа, в сторону того же tc с "заруливанием в пустоту" клиентов с отрицательным балансом.

Стало ещё лучше.

3й день как всё работает в боевом режиме, на локальном форуме лишь положительные отклики абонентов.

Всем огромное спасибо за помощь и содействие.

Изменено 6 ноября, 2009 пользователем pchol

[stelsik]

Подскажите как построили хеш фильтры