Jump to content
Калькуляторы

"Медленный" nat сервер посоветуйте как вылечить

Добрый день.

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

Медленность характеризуется задержками при сёрфинге на 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, ибо он собран монолитом в ядре, практически со всеми опциями.

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

Edited by pchol

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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 ? Оно включено вроде как...

Edited by pchol

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

#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

 

Share this post


Link to post
Share on other sites

pchol

 

ethtool -S eth2

ethtool -S eth3

 

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

 

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

 

Share this post


Link to post
Share on other sites

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 правил на дроп практически нулевые.

Edited by pchol

Share this post


Link to post
Share on other sites

Сделал...

 

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 относительно второго проца вообще стоят на месте.

Edited by pchol

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Edited by pchol

Share this post


Link to post
Share on other sites
Попадания в те 350 правил на дроп практически нулевые
Важно не столько попадание, сколько наличние самой проверки. Если у Вас 350 правил "не попадают", а потом одно посли них "попадает" - на каждый пакет всеравно приходится куча лишних действий.

 

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

Edited by pchol

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this