pchol Posted April 25, 2010 · Report post Добрый день. Есть машина выполняющая функции NAT + shaper(u32 hash, htb). Вчера вечером заметил проблему. В ЧНН прерывания перестали расходится равномерно и на одном из процов ядра поочерёдно улетали в полку, эти мооменты сопровождались возрастанием пинга и т д. Сетевуха оказалась внутренней, на которой как раз таки висят все правила шейпера. По процессам оказалось что отжирает всё ksoftirqd. Запустил oprofile и увидел вот такую картинку. 16335217 33.8280 cls_u32 11453172 23.7180 nf_conntrack 6063383 12.5564 e1000e 3155108 6.5338 ip_tables 2607395 5.3996 sch_htb 2077117 4.3014 libnetsnmp.so.15.1.2 1299551 2.6912 processor 1177341 2.4381 sch_sfq 902099 1.8681 nf_nat Через машину ходит всего навсего 300мбит. pps ~ 75к. Особенность в том что данная проблема появляется лишь тогда когда канал "упирается в полку". Тоесть на загрузке в 280 мбит всё работает отлично прерывания расходятся нагрузка порядка 20% по ядрам. как только доходит до 300 вклинивает. на серваке 2х Xeon E5410 2 сетевухи intel 1000PT. driver: e1000e version: 1.0.2-k2 Прерывания распределены 1 сетевуха - 1 физический проц. cache misses не наблюдается. В шейпере на исходящий трафик порядка 3к классов, на входящий повешен лишь один ingress полисер. Не подскажите ли в чём может быть проблема ? Share this post Link to post Share on other sites
Lynx10 Posted April 25, 2010 · Report post Добрый день.Есть машина выполняющая функции NAT + shaper(u32 hash, htb). Вчера вечером заметил проблему. В ЧНН прерывания перестали расходится равномерно и на одном из процов ядра поочерёдно улетали в полку, эти мооменты сопровождались возрастанием пинга и т д. Сетевуха оказалась внутренней, на которой как раз таки висят все правила шейпера. По процессам оказалось что отжирает всё ksoftirqd. Запустил oprofile и увидел вот такую картинку. 16335217 33.8280 cls_u32 11453172 23.7180 nf_conntrack 6063383 12.5564 e1000e 3155108 6.5338 ip_tables 2607395 5.3996 sch_htb 2077117 4.3014 libnetsnmp.so.15.1.2 1299551 2.6912 processor 1177341 2.4381 sch_sfq 902099 1.8681 nf_nat Через машину ходит всего навсего 300мбит. pps ~ 75к. Особенность в том что данная проблема появляется лишь тогда когда канал "упирается в полку". Тоесть на загрузке в 280 мбит всё работает отлично прерывания расходятся нагрузка порядка 20% по ядрам. как только доходит до 300 вклинивает. на серваке 2х Xeon E5410 2 сетевухи intel 1000PT. driver: e1000e version: 1.0.2-k2 Прерывания распределены 1 сетевуха - 1 физический проц. cache misses не наблюдается. В шейпере на исходящий трафик порядка 3к классов, на входящий повешен лишь один ingress полисер. Не подскажите ли в чём может быть проблема ? количество пакетов увеличивается когда упирается в полку ? Share this post Link to post Share on other sites
pchol Posted April 25, 2010 · Report post в районе 70к так и остаётся. Share this post Link to post Share on other sites
photon Posted April 25, 2010 · Report post Есть мнение, что надо увеличить величину rx и tx rings с помощью ethtool. Share this post Link to post Share on other sites
Умник Posted April 25, 2010 · Report post Покажите ethtool -S ethX для Ваших интерфейсов. Share this post Link to post Share on other sites
pchol Posted April 25, 2010 · Report post ethtool -S eth0 NIC statistics: rx_packets: 16786624803 tx_packets: 14920355077 rx_bytes: 8254048196095 tx_bytes: 8255327403974 rx_broadcast: 743878 tx_broadcast: 108894 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: 30215 rx_missed_errors: 38969 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: 4 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 770 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: 8254048196095 rx_csum_offload_good: 11655316117 rx_csum_offload_errors: 285549 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 ethtool -S eth1 NIC statistics: rx_packets: 15041033456 tx_packets: 15689566327 rx_bytes: 8290478085178 tx_bytes: 8004268794187 rx_broadcast: 55707 tx_broadcast: 63188 rx_multicast: 15872 tx_multicast: 36090 rx_errors: 0 tx_errors: 0 tx_dropped: 0 multicast: 15872 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 162646 rx_missed_errors: 78741 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: 3 tx_restart_queue: 7 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 1800 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: 8290478085178 rx_csum_offload_good: 14436081449 rx_csum_offload_errors: 54184 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 ethtool -g eth1 Ring parameters for eth1: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 2048 RX Mini: 0 RX Jumbo: 0 TX: 2048 Я вобщем то всегда думал если буфера не хватает то дропы растут постепенно а не пиком с 0 до 600п/с. Увеличение до 4096 ни даёт ровным счётом ничего. Share this post Link to post Share on other sites
pchol Posted April 26, 2010 · Report post Снова чнн, снова проблема =( Share this post Link to post Share on other sites
DemYaN Posted April 27, 2010 (edited) · Report post хеш-фильтры правильно построены? Edited April 27, 2010 by DemYaN Share this post Link to post Share on other sites
pchol Posted April 27, 2010 · Report post Вроде да. Примерно следующая конструкия: tc filter add dev eth1 parent 10: prio 5 handle 10: protocol ip u32 divisor 256 tc filter add dev eth1 protocol ip parent 10: prio 5 u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 10: tc filter add dev eth1 protocol ip parent 10: prio 5 u32 ht 10:60 match ip dst 192.168.0.96/32 flowid 10:3003 tc class add dev eth1 parent 10:1 classid 10:3003 htb rate 2160kbit burst 2160kbit tc qdisc add dev eth1 parent 10:3003 handle 3003: sfq perturb 10 Share this post Link to post Share on other sites
DemYaN Posted April 27, 2010 (edited) · Report post нужно многоуровневые строить Edited April 27, 2010 by DemYaN Share this post Link to post Share on other sites
pchol Posted April 27, 2010 · Report post Это всё хорошо, но вам не кажется странным скачок по нагрузкам ? Чтобы было понятней вот пара графиков. Помоему дело тут не в фильтрах... хотя могу и ошибаться. Share this post Link to post Share on other sites
photon Posted April 27, 2010 (edited) · Report post Ну такой скачок значит, что какая-то область памяти забивается. Если это хэш (а в Линуксовом сетевом стеке многое сделано на хэшах), то начинает резко расти число коллизий, производительность падает, и происходит дикий расход процессорного времени. Как обстоят дела с максимальным числом стейтов в iptables и памятью ядра, выделяемой под sk_buff-ы (насколько я помню, это параметры net/core/wmem_max, rmem_max, wmem_default, rmem_default)? Edited April 27, 2010 by photon Share this post Link to post Share on other sites
pchol Posted April 27, 2010 (edited) · Report post net.core.rmem_default = 124928 net.core.rmem_max = 131071 net.core.wmem_default = 124928 net.core.wmem_max = 131071 net.ipv4.netfilter.ip_conntrack_max = 296608 В моменты проблем таблица коннтраков не забита. Edited April 27, 2010 by pchol Share this post Link to post Share on other sites
photon Posted April 27, 2010 (edited) · Report post Кстати, забыл спросить, какие размеры и qdisc'и у дочерних очередей? Причина может быть в этом. Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно. Edited April 27, 2010 by photon Share this post Link to post Share on other sites
pchol Posted April 27, 2010 · Report post Прощу прощения немного не понял про qdisc и дочерние очереди. Имеете ввиду размеры потоков в классах ? Везде htb. Начиная от корня заканчивая классами клиентов. опять же не совсем понял про Надо очереди пакетов по 50 и pfifoSFQ на высокоскоростных тарифах уберу. Share this post Link to post Share on other sites
photon Posted April 28, 2010 · Report post Прощу прощения немного не понял про qdisc и дочерние очереди.Имеете ввиду размеры потоков в классах ? Везде htb. Начиная от корня заканчивая классами клиентов. У каждого дочернего класса HTB должен быть задан бесклассовый leaf qdisc. Обычно это sfq, pfifo или bfifo.tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 50 Для дисциплины pfifo длина очереди задается параметром limit. Неплохо бы еще подкрутить длину общей очереди для исходящего трафика: ifconfig eth0 txqueuelen ... Share this post Link to post Share on other sites
Lynx10 Posted April 28, 2010 · Report post Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно. почему ? Share this post Link to post Share on other sites
photon Posted April 28, 2010 · Report post Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы. Share this post Link to post Share on other sites
pchol Posted April 28, 2010 · Report post А почему вы рекомендуете limit 50 ? Share this post Link to post Share on other sites
DemYaN Posted April 28, 2010 (edited) · Report post Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы.cудя по выводу профайлера, который привел топикстартер, sfq ест не много:1177341 2.4381 sch_sfq сам использую sfq, классов около 4000: 1023.00 - 1.2% : sfq_enqueue [sch_sfq] Edited April 28, 2010 by DemYaN Share this post Link to post Share on other sites
Lynx10 Posted April 28, 2010 · Report post Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы. вопросов нет что просто вошёл вышел будет меньше нагружать чем перераспределение - вопрос только насколько это критично Share this post Link to post Share on other sites
pchol Posted April 28, 2010 · Report post Интересная такая ситуация. Убрал SFQ на тарифах со скоростями выше 2мбит. Вечер прошёл спокойно. Но на тарифах свыше 2мбит с sfq на сёрфинге работало лучше чем с pfifo. Может это конечно субъективное мнение, но всё же. Есть у кого какие либо идеи какова "граница", при которой начинаются проблемы ? Или идеи как "расширить" эту границу. По моим наблюдениям (хотя может быть это и не так), проблема возникает в тех случаях когда появляется несколько пользователей которые создают pps порядка 1к (тарифы 5-10мбит). Share this post Link to post Share on other sites
photon Posted April 28, 2010 (edited) · Report post Но на тарифах свыше 2мбит с sfq на сёрфинге работало лучше чем с pfifo.Когда человек с большим каналом начинает качать торренты, у него открывается несколько сотен или даже тысяч соединений, под которые дисциплиной SFQ создаются динамические очереди. Их обработка отнимает память и процессорное время шейпера. Ради улучшения веб-серфинга оставлять SFQ смысла нет, т.к. разумный пользователь сам ограничит скорость в своем торрент-клиенте. Я считаю, что заниматься QoS внутри пользовательского канала -- не провайдерское дело. Приоритезация трафика должна делаться пользовательским оборудованием на основе поля ToS/DSCP. Если сетевое приложение написано нормально, у отправляемых пакетов будут правильно выставлены метки ToS, по которым ОС с адекватным сетевым стеком делает приоритезацию исходящего трафика. В Линуксе приоритезация по ToS включена по умолчанию (см. описание дисциплины pfifo_fast). В Windows начиная с XP она тоже есть. В Vista/Server 2008 вроде даже какое-то новое API по поводу QoS появилось. Есть у кого какие либо идеи какова "граница", при которой начинаются проблемы ?Ну у меня, к примеру, был шейпер на Linux с сетевухами BCM5714 (драйвер tg3) и процессором Q6600, который тянул без потерь до 700 Мбит/с с пакетрейтами 200-250 kpps. HTB и pfifo, одноуровневые хэш-фильтры. Edited April 28, 2010 by photon Share this post Link to post Share on other sites
pchol Posted April 28, 2010 (edited) · Report post Спасибо за пояснения. Но всё же вы не ответили откуда значение 50 в pfifo ? Про границу я имел ввиду границу для применения sfq. Edited April 28, 2010 by pchol Share this post Link to post Share on other sites
photon Posted April 28, 2010 (edited) · Report post Спасибо за пояснения.Но всё же вы не ответили откуда значение 50 в pfifo ? Это просто некое эмпирическое значение, я особо не тестировал на этот счет. Для канала 20Мбит/с очередь в 50 пакетов -- это нормально, но для 2Мбит/с конечно много. Про границу я имел ввиду границу для применения sfq.Я и говорю. Провайдеру с >1000 пользователей онлайн лучше не заниматься QoS внутри пользовательского канала на PC-шном железе. Пускай пользователи сами настраивают свои программы, потребляющие трафик. Edited April 28, 2010 by photon Share this post Link to post Share on other sites
