pchol Опубликовано 31 октября, 2009 (изменено) · Жалоба Добрый день. Сложилась такая ситуация. Вечерами, при повышении активности пользователей замечена более медленная работа инета. Медленность характеризуется задержками при сёрфинге на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dmitr_ Опубликовано 31 октября, 2009 · Жалоба а polling есть какойнить?вообще проц как првило не играет решающей роли в скорости работы маршрутизатора, роль играет память, оперативная, ибо все процессы происходят в ней. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 31 октября, 2009 (изменено) · Жалоба А может точнее подскажите что нужно показать /посмотреть ? 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 31 октября, 2009 · Жалоба Судя по oprofile и mpstat - узких мест нет. Скорее всего неправильная конфигурация шейпера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 31 октября, 2009 · Жалоба 3к статичных параллельных классов не есть гуд.... сам понимаю... но какие варианты решения ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 ноября, 2009 (изменено) · Жалоба Классов может быть сколько угодно (от 1 до ffff). Главное использовать эффективные фильтры (u32 hashing filters или flow), чтобы пакеты не проходили по сотням правил. Изменено 1 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 1 ноября, 2009 · Жалоба pchol ethtool -S eth2 ethtool -S eth3 Прерывания распихиваются вроде бы нормальноОни не "распихиваются", "прибейте" два рабочих интерфейса к ядрам с общим L2 кешем - будет проще смотреть загрузку и эффективней будут работать кеши CPU. Скорее всего вам давно пора оптимизировать правила iptables (ipset) и обязательно использовать хеширование в tc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 1 ноября, 2009 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 1 ноября, 2009 (изменено) · Жалоба Сделал... 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 ноября, 2009 (изменено) · Жалоба А хэширование в tc вы уже сделали? Если да, то действительно все из-за правил iptables. Изменено 1 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 1 ноября, 2009 (изменено) · Жалоба Нет, займусь тогда им... Изменено 1 ноября, 2009 пользователем pchol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 1 ноября, 2009 · Жалоба Попадания в те 350 правил на дроп практически нулевыеВажно не столько попадание, сколько наличние самой проверки. Если у Вас 350 правил "не попадают", а потом одно посли них "попадает" - на каждый пакет всеравно приходится куча лишних действий. Вроде всё так да ? eth2 на одном проце, eth3 на втором...Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 1 ноября, 2009 · Жалоба Я имел ввиду именно ядра (скорее всего CPU0 и CPU1 с общим L2). Нагрузка у Вас не разделяется между ядрами, они все просто работают по очереди, загрязняя каждый свой кеш и постоянно поддерживая их когерентность (это не катастрофично, но все же влияет на производительность). Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 ноября, 2009 · Жалоба А пакеты у вас по дороге не бьются? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 2 ноября, 2009 · Жалоба Подскажите пожалуйста, как тогда определить какие ядра имеют общий кеш ? На свежих ядрах можно посмотреть в /sys/devices/system/cpu/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 6 ноября, 2009 (изменено) · Жалоба Небольшой отчёт... Разнёс прерывания от сетевух на 4 ядра (2 на одном процессоре физическом, 2 на другом), в результате ksoftirqd замер на месте и двигается только иногда во время пиковых нагрузок. Сделал хеширование в tc, значительно ускорилась работа. Отказался от ipset и iptables для дропа, в сторону того же tc с "заруливанием в пустоту" клиентов с отрицательным балансом. Стало ещё лучше. 3й день как всё работает в боевом режиме, на локальном форуме лишь положительные отклики абонентов. Всем огромное спасибо за помощь и содействие. Изменено 6 ноября, 2009 пользователем pchol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stelsik Опубликовано 19 ноября, 2009 · Жалоба Подскажите как построили хеш фильтры Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...