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

Linux shaper, проблема с u32 cls_u32 съедает проц

Добрый день.

Есть машина выполняющая функции 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
Добрый день.

Есть машина выполняющая функции 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

в районе 70к так и остаётся.

Share this post


Link to post
Share on other sites

Есть мнение, что надо увеличить величину rx и tx rings с помощью ethtool.

Share this post


Link to post
Share on other sites

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

Снова чнн, снова проблема =(

Share this post


Link to post
Share on other sites

хеш-фильтры правильно построены?

Edited by DemYaN

Share this post


Link to post
Share on other sites

Вроде да.

Примерно следующая конструкия:

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

нужно многоуровневые строить

Edited by DemYaN

Share this post


Link to post
Share on other sites

Это всё хорошо, но вам не кажется странным скачок по нагрузкам ?

Чтобы было понятней вот пара графиков.

Помоему дело тут не в фильтрах... хотя могу и ошибаться.

post-56053-1272405267_thumb.png

post-56053-1272405273_thumb.png

Share this post


Link to post
Share on other sites

Ну такой скачок значит, что какая-то область памяти забивается. Если это хэш (а в Линуксовом сетевом стеке многое сделано на хэшах), то начинает резко расти число коллизий, производительность падает, и происходит дикий расход процессорного времени. Как обстоят дела с максимальным числом стейтов в iptables и памятью ядра, выделяемой под sk_buff-ы (насколько я помню, это параметры net/core/wmem_max, rmem_max, wmem_default, rmem_default)?

Edited by photon

Share this post


Link to post
Share on other sites

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 by pchol

Share this post


Link to post
Share on other sites

Кстати, забыл спросить, какие размеры и qdisc'и у дочерних очередей? Причина может быть в этом. Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно.

Edited by photon

Share this post


Link to post
Share on other sites

Прощу прощения немного не понял про qdisc и дочерние очереди.

Имеете ввиду размеры потоков в классах ?

Везде htb. Начиная от корня заканчивая классами клиентов.

опять же не совсем понял про

Надо очереди пакетов по 50 и pfifo
SFQ на высокоскоростных тарифах уберу.

Share this post


Link to post
Share on other sites
Прощу прощения немного не понял про 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

Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно.

почему ?

Share this post


Link to post
Share on other sites

Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы.

Share this post


Link to post
Share on other sites

А почему вы рекомендуете limit 50 ?

Share this post


Link to post
Share on other sites
Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы.
cудя по выводу профайлера, который привел топикстартер, sfq ест не много:

1177341 2.4381 sch_sfq

 

сам использую sfq, классов около 4000:

1023.00 - 1.2% : sfq_enqueue [sch_sfq]

Edited by DemYaN

Share this post


Link to post
Share on other sites

Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы.

вопросов нет что просто вошёл вышел будет меньше нагружать чем перераспределение - вопрос только насколько это критично

Share this post


Link to post
Share on other sites

Интересная такая ситуация.

Убрал SFQ на тарифах со скоростями выше 2мбит.

Вечер прошёл спокойно.

Но на тарифах свыше 2мбит с sfq на сёрфинге работало лучше чем с pfifo.

Может это конечно субъективное мнение, но всё же.

Есть у кого какие либо идеи какова "граница", при которой начинаются проблемы ?

Или идеи как "расширить" эту границу.

По моим наблюдениям (хотя может быть это и не так), проблема возникает в тех случаях когда появляется несколько пользователей которые создают pps порядка 1к (тарифы 5-10мбит).

Share this post


Link to post
Share on other sites
Но на тарифах свыше 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 by photon

Share this post


Link to post
Share on other sites

Спасибо за пояснения.

Но всё же вы не ответили откуда значение 50 в pfifo ?

Про границу я имел ввиду границу для применения sfq.

Edited by pchol

Share this post


Link to post
Share on other sites
Спасибо за пояснения.

Но всё же вы не ответили откуда значение 50 в pfifo ?

Это просто некое эмпирическое значение, я особо не тестировал на этот счет. Для канала 20Мбит/с очередь в 50 пакетов -- это нормально, но для 2Мбит/с конечно много.

 

Про границу я имел ввиду границу для применения sfq.
Я и говорю. Провайдеру с >1000 пользователей онлайн лучше не заниматься QoS внутри пользовательского канала на PC-шном железе. Пускай пользователи сами настраивают свои программы, потребляющие трафик.
Edited by photon

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