pchol Posted October 31, 2009 Posted October 31, 2009 (edited) Добрый день. Сложилась такая ситуация. Вечерами, при повышении активности пользователей замечена более медленная работа инета. Медленность характеризуется задержками при сёрфинге на 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 October 31, 2009 by pchol Вставить ник Quote
_dmitr_ Posted October 31, 2009 Posted October 31, 2009 а polling есть какойнить?вообще проц как првило не играет решающей роли в скорости работы маршрутизатора, роль играет память, оперативная, ибо все процессы происходят в ней. Вставить ник Quote
pchol Posted October 31, 2009 Author Posted October 31, 2009 (edited) А может точнее подскажите что нужно показать /посмотреть ? 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 October 31, 2009 by pchol Вставить ник Quote
nuclearcat Posted October 31, 2009 Posted October 31, 2009 Судя по oprofile и mpstat - узких мест нет. Скорее всего неправильная конфигурация шейпера. Вставить ник Quote
pchol Posted October 31, 2009 Author Posted October 31, 2009 3к статичных параллельных классов не есть гуд.... сам понимаю... но какие варианты решения ? Вставить ник Quote
photon Posted November 1, 2009 Posted November 1, 2009 (edited) Классов может быть сколько угодно (от 1 до ffff). Главное использовать эффективные фильтры (u32 hashing filters или flow), чтобы пакеты не проходили по сотням правил. Edited November 1, 2009 by photon Вставить ник Quote
pchol Posted November 1, 2009 Author Posted November 1, 2009 Делается вот так на каждого клиента. #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 Вставить ник Quote
vitalyb Posted November 1, 2009 Posted November 1, 2009 pchol ethtool -S eth2 ethtool -S eth3 Прерывания распихиваются вроде бы нормальноОни не "распихиваются", "прибейте" два рабочих интерфейса к ядрам с общим L2 кешем - будет проще смотреть загрузку и эффективней будут работать кеши CPU. Скорее всего вам давно пора оптимизировать правила iptables (ipset) и обязательно использовать хеширование в tc. Вставить ник Quote
pchol Posted November 1, 2009 Author Posted November 1, 2009 (edited) 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 November 1, 2009 by pchol Вставить ник Quote
pchol Posted November 1, 2009 Author Posted November 1, 2009 (edited) Сделал... 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 November 1, 2009 by pchol Вставить ник Quote
photon Posted November 1, 2009 Posted November 1, 2009 (edited) А хэширование в tc вы уже сделали? Если да, то действительно все из-за правил iptables. Edited November 1, 2009 by photon Вставить ник Quote
pchol Posted November 1, 2009 Author Posted November 1, 2009 (edited) Нет, займусь тогда им... Edited November 1, 2009 by pchol Вставить ник Quote
vitalyb Posted November 1, 2009 Posted November 1, 2009 Попадания в те 350 правил на дроп практически нулевыеВажно не столько попадание, сколько наличние самой проверки. Если у Вас 350 правил "не попадают", а потом одно посли них "попадает" - на каждый пакет всеравно приходится куча лишних действий. Вроде всё так да ? eth2 на одном проце, eth3 на втором...Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность). Вставить ник Quote
pchol Posted November 1, 2009 Author Posted November 1, 2009 Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность). Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ? Вставить ник Quote
Ivan_83 Posted November 1, 2009 Posted November 1, 2009 А пакеты у вас по дороге не бьются? Вставить ник Quote
vitalyb Posted November 2, 2009 Posted November 2, 2009 Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ? На свежих ядрах можно посмотреть в /sys/devices/system/cpu/ Вставить ник Quote
pchol Posted November 6, 2009 Author Posted November 6, 2009 (edited) Небольшой отчёт... Разнёс прерывания от сетевух на 4 ядра (2 на одном процессоре физическом, 2 на другом), в результате ksoftirqd замер на месте и двигается только иногда во время пиковых нагрузок. Сделал хеширование в tc, значительно ускорилась работа. Отказался от ipset и iptables для дропа, в сторону того же tc с "заруливанием в пустоту" клиентов с отрицательным балансом. Стало ещё лучше. 3й день как всё работает в боевом режиме, на локальном форуме лишь положительные отклики абонентов. Всем огромное спасибо за помощь и содействие. Edited November 6, 2009 by pchol Вставить ник Quote
stelsik Posted November 19, 2009 Posted November 19, 2009 Подскажите как построили хеш фильтры Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.