pchol Опубликовано 25 апреля, 2010 Добрый день. Есть машина выполняющая функции 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 полисер. Не подскажите ли в чём может быть проблема ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 25 апреля, 2010 Добрый день.Есть машина выполняющая функции 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 полисер. Не подскажите ли в чём может быть проблема ? количество пакетов увеличивается когда упирается в полку ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 25 апреля, 2010 в районе 70к так и остаётся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 25 апреля, 2010 Есть мнение, что надо увеличить величину rx и tx rings с помощью ethtool. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 25 апреля, 2010 Покажите ethtool -S ethX для Ваших интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 25 апреля, 2010 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 ни даёт ровным счётом ничего. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 26 апреля, 2010 Снова чнн, снова проблема =( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 27 апреля, 2010 (изменено) хеш-фильтры правильно построены? Изменено 27 апреля, 2010 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 27 апреля, 2010 Вроде да. Примерно следующая конструкия: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 27 апреля, 2010 (изменено) нужно многоуровневые строить Изменено 27 апреля, 2010 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 27 апреля, 2010 Это всё хорошо, но вам не кажется странным скачок по нагрузкам ? Чтобы было понятней вот пара графиков. Помоему дело тут не в фильтрах... хотя могу и ошибаться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 27 апреля, 2010 (изменено) Ну такой скачок значит, что какая-то область памяти забивается. Если это хэш (а в Линуксовом сетевом стеке многое сделано на хэшах), то начинает резко расти число коллизий, производительность падает, и происходит дикий расход процессорного времени. Как обстоят дела с максимальным числом стейтов в iptables и памятью ядра, выделяемой под sk_buff-ы (насколько я помню, это параметры net/core/wmem_max, rmem_max, wmem_default, rmem_default)? Изменено 27 апреля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 27 апреля, 2010 (изменено) 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 В моменты проблем таблица коннтраков не забита. Изменено 27 апреля, 2010 пользователем pchol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 27 апреля, 2010 (изменено) Кстати, забыл спросить, какие размеры и qdisc'и у дочерних очередей? Причина может быть в этом. Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно. Изменено 27 апреля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 27 апреля, 2010 Прощу прощения немного не понял про qdisc и дочерние очереди. Имеете ввиду размеры потоков в классах ? Везде htb. Начиная от корня заканчивая классами клиентов. опять же не совсем понял про Надо очереди пакетов по 50 и pfifoSFQ на высокоскоростных тарифах уберу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 апреля, 2010 Прощу прощения немного не понял про 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 ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 28 апреля, 2010 Надо очереди пакетов по 50 и pfifo. sfq на больших пакетрейтах использовать нежелательно. почему ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 апреля, 2010 Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 28 апреля, 2010 А почему вы рекомендуете limit 50 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 28 апреля, 2010 (изменено) Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы.cудя по выводу профайлера, который привел топикстартер, sfq ест не много:1177341 2.4381 sch_sfq сам использую sfq, классов около 4000: 1023.00 - 1.2% : sfq_enqueue [sch_sfq] Изменено 28 апреля, 2010 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 28 апреля, 2010 Алгоритм SFQ сложнее FIFO, расходуются лишние ресурсы. вопросов нет что просто вошёл вышел будет меньше нагружать чем перераспределение - вопрос только насколько это критично Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 28 апреля, 2010 Интересная такая ситуация. Убрал SFQ на тарифах со скоростями выше 2мбит. Вечер прошёл спокойно. Но на тарифах свыше 2мбит с sfq на сёрфинге работало лучше чем с pfifo. Может это конечно субъективное мнение, но всё же. Есть у кого какие либо идеи какова "граница", при которой начинаются проблемы ? Или идеи как "расширить" эту границу. По моим наблюдениям (хотя может быть это и не так), проблема возникает в тех случаях когда появляется несколько пользователей которые создают pps порядка 1к (тарифы 5-10мбит). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 апреля, 2010 (изменено) Но на тарифах свыше 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, одноуровневые хэш-фильтры. Изменено 28 апреля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 28 апреля, 2010 (изменено) Спасибо за пояснения. Но всё же вы не ответили откуда значение 50 в pfifo ? Про границу я имел ввиду границу для применения sfq. Изменено 28 апреля, 2010 пользователем pchol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 апреля, 2010 (изменено) Спасибо за пояснения.Но всё же вы не ответили откуда значение 50 в pfifo ? Это просто некое эмпирическое значение, я особо не тестировал на этот счет. Для канала 20Мбит/с очередь в 50 пакетов -- это нормально, но для 2Мбит/с конечно много. Про границу я имел ввиду границу для применения sfq.Я и говорю. Провайдеру с >1000 пользователей онлайн лучше не заниматься QoS внутри пользовательского канала на PC-шном железе. Пускай пользователи сами настраивают свои программы, потребляющие трафик. Изменено 28 апреля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
