Перейти к содержимому
Калькуляторы

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 полисер.

 

Не подскажите ли в чём может быть проблема ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

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

 

Не подскажите ли в чём может быть проблема ?

количество пакетов увеличивается когда упирается в полку ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Покажите ethtool -S ethX для Ваших интерфейсов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 ни даёт ровным счётом ничего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем DemYaN

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вроде да.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем DemYaN

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

post-56053-1272405267_thumb.png

post-56053-1272405273_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

В моменты проблем таблица коннтраков не забита.

Изменено пользователем pchol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прощу прощения немного не понял про 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 ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

почему ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

1177341 2.4381 sch_sfq

 

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

1023.00 - 1.2% : sfq_enqueue [sch_sfq]

Изменено пользователем DemYaN

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но на тарифах свыше 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, одноуровневые хэш-фильтры.
Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем pchol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.