Стич Опубликовано 25 октября, 2012 (изменено) · Жалоба На бордере образуется полка в 2Гбит/c. На нем шейпется юзеры при помощи imq + tc htb + hashing filters. Загрузка процесоров 30%. Отключаю шейпер на tc трафик сразу же поднимается выше 3Гбит/c. Изменено 25 октября, 2012 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmitry_ Опубликовано 25 октября, 2012 · Жалоба rate и ceil случаем не 2000mbit у корневого класса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 26 октября, 2012 · Жалоба Если бы так было я был бы счастлив. Если кто сталкивался с подобной проблемой отпишите плиз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 26 октября, 2012 · Жалоба Возможно, проблема в imq. См. сообщение по аналогичной проблеме с ifb: http://forum.nag.ru/forum/index.php?showtopic=48301&view=findpost&p=761424 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 26 октября, 2012 · Жалоба Когда я выключаю шейпер трафик всё равно бегает через IMQ, поэтому проблемы с imq можно исключить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 октября, 2012 · Жалоба Помоему была такая проблема в HTB, корень лежит в его принципе работы и нагрузке на таймеры. Попробуйте HFSC Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 26 октября, 2012 (изменено) · Жалоба В конфиге ядра Linux должен быть параметр HZ, определяющий разрешение таймеров, как и во FreeBSD. Если проблема действительно в HTB и таймерах, то его просто надо увеличить, либо перейти на HFSC. По умолчанию там вроде HZ=500. Другой причиной может быть недостаточно большая длина очередей у дочерних классов. Изменено 26 октября, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 27 октября, 2012 (изменено) · Жалоба Спасибо за ответы. У меня (kernel 3.2.21) # CONFIG_NO_HZ is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 Наверное попробую перейти на HFSC. HFSC имеет ли какие нибудь особенности настройки, либо рекомендуемые параметры. Поделитесь плиз. Тут на форуме прочел что при переходе с htb на hfsc достаточно поменять htb rate ... ceil ... на hfsc sc rate ... ul rate ... Так ли это? Изменено 27 октября, 2012 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 27 октября, 2012 · Жалоба HZ лучше ставить 1000 Да, где-то так, хотя шейпер лучше перепроверить. Есть еще один очень опасный нюанс (для удаленного управления) - весь "непрописанный" траффик в HFSC дропается, в этом отличие от HTB. Потому _обязательно_ отдельным классом прописать дефолт, и ARP траффик. Где-то так: filter add dev eth0 prio 20 protocol all parent 1: u32 match u32 0 0 flowid 1:9 Обратите внимание на "protocol all", это важно, не "protocol ip". Я обычно перед включением шейпера делаю в скрине отложенную перезагрузку или удаление шейпера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 27 октября, 2012 · Жалоба спасибо. Для пропуска не прописанного трафика default в qdisc(tc qdisc add dev imq0 root handle 1: hfsc default 9) достаточно будет или лучше filter прописать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 27 октября, 2012 · Жалоба Лучше прописать. С default у меня как-то не сложилось однажды, и привело к полному отсутствию доступа к железке, когда истекли ARP таймауты :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 30 октября, 2012 · Жалоба Сделал тиклес ядро вот так. # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_NO_HZ=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 Не помогло. Поменял ядро с 3.2.21 на 3.4.16 то же не помогло. Заменил htb на HFSC, система встаёт колом на нагрузке около 1гбит/c скорость резко падает до 500МБит/c. У юзеров падает скорость, возрастают пинги, при этом htop показывает загрузку ядер около 10%. Вернул htb. Он хоть до 2ГБит/c тянет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 октября, 2012 · Жалоба Возможно, стоит написать bug report по этому поводу или обратиться напрямую к автору htb. Очевидно, что ее не тестировали при таких больших скоростях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 30 октября, 2012 · Жалоба Мне кажется дело несколько в другом. А сколько у вас классов и фильтров? Как построены фильтры, есть ли древовидные хеши, и сколько итераций среднестатический пакет проходит в фильтрах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
necrozz Опубликовано 31 октября, 2012 · Жалоба Сделал тиклес ядро вот так. # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_NO_HZ=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 Не помогло. Поменял ядро с 3.2.21 на 3.4.16 то же не помогло. Заменил htb на HFSC, система встаёт колом на нагрузке около 1гбит/c скорость резко падает до 500МБит/c. У юзеров падает скорость, возрастают пинги, при этом htop показывает загрузку ядер около 10%. Вернул htb. Он хоть до 2ГБит/c тянет. Если посмотреть perf top, у вас там часом spin_lock не зашкаливает в такие моменты ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 31 октября, 2012 · Жалоба Еще как вариант глянуть на правила, возможно сами шейперы нарисованы неправильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 31 октября, 2012 · Жалоба Если посмотреть perf top, у вас там часом spin_lock не зашкаливает в такие моменты ? Вывод oprofiled, загрузка ядер около 30%: CPU_CLK_UNHALT...| samples| %| ------------------ 131447636 14.6290 igb 122092771 13.5879 cls_u32 113287590 12.6080 imq 102010412 11.3529 nf_conntrack 98705075 10.9850 sch_htb 79388572 8.8353 ip_tables 43077395 4.7942 ipt_NETFLOW 36312895 4.0413 ip_set 35044292 3.9001 bonding Еще как вариант глянуть на правила, возможно сами шейперы нарисованы неправильно. Сегодня попробую убрать клиентские классы и фильтры оставив только базовые. Посмотрю уйдет ли проблема. Так же попробую шейпер без imq. По результатам отпишусь. Спасибо за помощь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 31 октября, 2012 · Жалоба Особенно важно убрать фильтры, судя по всему у вас их много. Но вообще imq + HTB + conntrack(nat?) + netflow + еще видимо правила на iptables и на 2+ гигабита - это многовато для одной машинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 31 октября, 2012 · Жалоба Если бы видел что проц и память на исходе, естественно бы разнёс нагрузку, но как раз этого не наблюдается. Машинка два X5650@2.67GHz. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 31 октября, 2012 (изменено) · Жалоба По предварительным результатам вроде проблема ушла. Сделал следующие. Убрал imq повесив htb шейпер на vlan интерфейс смотрящий в сторону юзеров, исходящий трафик отполисер фильтрами на ffff: дисцеплине этого интерфейса. Спасибо за помощь. Изменено 31 октября, 2012 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 31 октября, 2012 (изменено) · Жалоба Я же говорил. Интересно, как в этих псевдоустройствах реализована работа с данными: передачей указателя на sk_buff или созданием копии? Скорее всего второе, раз такие проблемы возникают. Изменено 31 октября, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 1 ноября, 2012 · Жалоба photon Да, Вы правы оказались, что imq упорно не вставляемое в ядро, что ifb упорно навязываемая ядром, работают совершенно одинаково. Ну зато экономия 15% загрузки cpu, в обмена на некие не удобства. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vinnipux Опубликовано 6 ноября, 2012 · Жалоба Подскажите, я вот сколько не мучаюсь, а мне не удается подтюнить все таким образом, что-бы умудряться до 2Гбит пережевывать и при этом что-бы HTB был активен. По наблюдениям упираюсь в полочку 1.3-1.4Гбит/сек, снимаю шейп - железо жует до 2Гбит в пиках. Роутер: Motherboard: Intel Corporation S1200BTL CPU: Intel® Xeon® CPU E31240 @ 3.30GHz 4-ядра + HT RAM: 2048 Mb (DIMM DDR3 Synchronous 1333 MHz) Две дуальных Интеловских сетевых карты E1G42ET с чипом 82576 (8 Tx/8 Rx очередей) - отличные карты. *-network:0 description: Ethernet interface product: 82576 Gigabit Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@0000:02:00.0 logical name: eth1 version: 01 serial: 90:e2:ba:01:00:ca size: 1Gbit/s capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=igb driverversion=4.0.1-k duplex=full firmware=1.21, 0x0000c822 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s resources: irq:17 memory:84020000-8403ffff memory:83c00000-83ffffff ioport:4020(size=32) memory:84050000-84053fff memory:83800000-83bfffff memory:840c0000-840dffff memory:840a0000-840bffff Использую Fedora release 16, ядро Linux 3.6.2-1.fc16.i686 SMP. Первый вопрос - имеет ли смысл использовать 64-х битную платформу, учитывая то, что все равно ширина шины PCI Express 32 бита для этой карты? Однозначного ответа на форуме я не нашел. Ядра менял, было из ветки 3.2.x, 3.5.x и сейчас 3.6.x. Разница заметил только в стратегии ITR по умолчанию в драйвере igb, в 3.6.x по умолчанию пытается генерить максимальное их количество ради low latency. Организованы сетевые карты в 2 bond-а, роутер прокачивает транзитный трафик. Поверх одного из bond-ов 2 vlan-а к upstream-у. Пытаюсь оставить шейпер, который ранее работал, пока транзитная скорость не превысила порог в 1.3-1.5Гбит/сек. Пакетов в эти моменты 190 - 220 kpps. [root@router ~]# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 0 19185494382 15 448 0 21329148281 0 0 0 BMmRU bond1 1500 0 25699052468 0 2 0 22855408501 0 0 0 BMmRU eth1 1500 0 12836963978 0 2 0 11465654686 0 0 0 BMsRU lo 16436 0 1558 0 0 0 1558 0 0 0 LRU p2p1 1500 0 12862089479 0 0 0 11389754828 0 0 0 BMsRU p3p1 1500 0 9587131662 15 423 0 10665163154 0 0 0 BMsRU p3p2 1500 0 9598368418 0 25 0 10663991273 0 0 0 BMsRU p4p1 1500 0 525383653 1 27230 0 702324681 0 0 0 BMRU vlan2221 1500 0 14003950137 0 0 0 14642263912 0 0 0 BMRU vlan2222 1500 0 5376330383 0 0 0 6784434053 0 0 0 BMRU Особых проблем здесь не вижу /sbin/tc class add dev bond0 parent 1: classid 1:2 htb rate 1950Mbit /sbin/tc class add dev bond0 parent 1:2 classid 1:20 htb rate 20Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:20 handle 20 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.248/29 classid 1:20 /sbin/tc class add dev bond0 parent 1:2 classid 1:25 htb rate 4Mbit ceil 10Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:25 handle 25 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.45 classid 1:25 /sbin/tc class add dev bond0 parent 1:2 classid 1:30 htb rate 2Mbit ceil 2Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:30 handle 30 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.240/29 classid 1:30 /sbin/tc class add dev bond0 parent 1:2 classid 1:35 htb rate 10Mbit ceil 50Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:35 handle 35 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.248/29 classid 1:35 /sbin/tc class add dev bond0 parent 1:2 classid 1:40 htb rate 10Mbit ceil 100Mbit prio 4 /sbin/tc qdisc add dev bond0 parent 1:40 handle 40 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.180/30 classid 1:40 /sbin/tc class add dev bond0 parent 1:2 classid 1:50 htb rate 8Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:50 handle 50 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.228/30 classid 1:50 /sbin/tc class add dev bond0 parent 1:2 classid 1:51 htb rate 8Mbit ceil 30Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:51 handle 51 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.188/30 classid 1:51 /sbin/tc class add dev bond0 parent 1:2 classid 1:60 htb rate 10Mbit ceil 100Mbit prio 2 /sbin/tc qdisc add dev bond0 parent 1:60 handle 60 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.232/30 classid 1:60 /sbin/tc class add dev bond0 parent 1:2 classid 1:70 htb rate 2Mbit ceil 10Mbit burst 512Kbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:70 handle 70 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.224/30 classid 1:70 /sbin/tc class add dev bond0 parent 1:2 classid 1:80 htb rate 4Mbit ceil 5Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:80 handle 80 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.86 classid 1:80 /sbin/tc class add dev bond0 parent 1:2 classid 1:9000 htb rate 100Mbit ceil 1950Mbit prio 1 /sbin/tc qdisc add dev bond0 parent 1:9000 handle 9000 pfifo limit 50000 Пробовал строить классы по разному, если выделять все свои сети в отдельный класс и матчить их по единой маске 146.11.40.0/21 и 191.21.12.0/22 то это приводит к плачевным результатам, становится ощутимой задержка, от десятков до сотен мсек, увеличивается в процентах _raw_spin_lock на полтора десятка, в общем решил упростить шейпер по максимуму. Но это все равно не помогает. Распределение прерываний CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 125 0 0 0 0 0 0 0 IO-APIC-edge timer 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 20: 410 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 22: 64 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 40: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 41: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 42: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 43: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 44: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 45: 255336 0 0 0 0 0 0 0 PCI-MSI-edge ahci 46: 2 0 0 0 0 0 0 0 PCI-MSI-edge eth1 47: 5991745 0 0 0 0 0 199810568 0 PCI-MSI-edge eth1-TxRx-0 48: 12901302 0 0 0 0 232654567 0 0 PCI-MSI-edge eth1-TxRx-1 49: 5974164 0 0 0 201890361 0 0 0 PCI-MSI-edge eth1-TxRx-2 50: 5730835 0 0 199537269 0 0 0 0 PCI-MSI-edge eth1-TxRx-3 51: 6169897 0 199089475 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-4 52: 6014566 199061856 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-5 53: 208085233 0 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-6 54: 6258764 0 0 0 0 0 0 200327414 PCI-MSI-edge eth1-TxRx-7 55: 632 0 0 0 0 0 89950 0 PCI-MSI-edge eth0 56: 2 0 0 0 0 0 0 0 PCI-MSI-edge p2p1 57: 6204529 0 0 0 198922711 0 0 0 PCI-MSI-edge p2p1-TxRx-0 58: 13394220 0 0 230589054 0 0 0 0 PCI-MSI-edge p2p1-TxRx-1 59: 6135941 0 199756903 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-2 60: 6639134 198238947 0 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-3 61: 205084685 0 0 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-4 62: 6208566 0 0 0 0 0 0 199051642 PCI-MSI-edge p2p1-TxRx-5 63: 5931442 0 0 0 0 0 199487980 0 PCI-MSI-edge p2p1-TxRx-6 64: 5977224 0 0 0 0 200533387 0 0 PCI-MSI-edge p2p1-TxRx-7 65: 1766399 0 0 0 89456666 0 0 0 PCI-MSI-edge p4p1-rx-0 66: 1991472 0 0 107225385 0 0 0 0 PCI-MSI-edge p4p1-tx-0 67: 3 0 0 0 0 0 0 0 PCI-MSI-edge p4p1 68: 2 0 0 0 0 0 0 0 PCI-MSI-edge p3p1 69: 211719881 0 0 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-0 70: 7012438 0 0 0 0 0 0 203903436 PCI-MSI-edge p3p1-TxRx-1 71: 7003509 0 0 0 0 0 203555130 0 PCI-MSI-edge p3p1-TxRx-2 72: 6919736 0 0 0 0 202754172 0 0 PCI-MSI-edge p3p1-TxRx-3 73: 7027187 0 0 0 204993214 0 0 0 PCI-MSI-edge p3p1-TxRx-4 74: 7139353 0 0 203823562 0 0 0 0 PCI-MSI-edge p3p1-TxRx-5 75: 6759960 0 204092355 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-6 76: 7204501 204422491 0 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-7 77: 2 0 0 0 0 0 0 0 PCI-MSI-edge p3p2 78: 6877916 0 0 0 0 0 0 204781334 PCI-MSI-edge p3p2-TxRx-0 79: 6393147 0 0 0 0 0 203716187 0 PCI-MSI-edge p3p2-TxRx-1 80: 7141383 0 0 0 0 204750428 0 0 PCI-MSI-edge p3p2-TxRx-2 81: 7022920 0 0 0 205615894 0 0 0 PCI-MSI-edge p3p2-TxRx-3 82: 6970851 0 0 204054467 0 0 0 0 PCI-MSI-edge p3p2-TxRx-4 83: 7004182 0 203495312 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-5 84: 6911389 204867882 0 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-6 85: 213496439 0 0 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-7 NMI: 91201 70585 69293 73489 58301 74423 66984 43383 Non-maskable interrupts LOC: 13766383 8523304 8673018 8005414 7866149 7767025 8371333 6477920 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 91201 70585 69293 73489 58301 74423 66984 43383 Performance monitoring interrupts IWI: 10 7 6 7 5 7 6 2 IRQ work interrupts RTR: 5 0 0 0 0 0 0 0 APIC ICR read retries RES: 385924 544144 22135 8521 6339 4366 3465 4986 Rescheduling interrupts CAL: 15186 17432 16232 17279 16851 29530 25873 22421 Function call interrupts TLB: 0 0 0 0 0 0 0 0 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 605 605 605 605 605 605 605 605 Machine check polls ERR: 0 MIS: 0 cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc [root@router ~]# mpstat -P ALL 1 Linux 3.6.2-1.fc16.i686 (router) 06.11.2012 _i686_ (8 CPU) 20:02:51 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:52 all 0,13 0,00 0,13 0,00 0,63 30,43 0,00 0,00 68,69 20:02:52 0 0,00 0,00 1,01 0,00 0,00 27,27 0,00 0,00 71,72 20:02:52 1 0,00 0,00 0,00 0,00 1,02 29,59 0,00 0,00 69,39 20:02:52 2 0,00 0,00 0,00 0,00 1,01 31,31 0,00 0,00 67,68 20:02:52 3 0,00 0,00 0,00 0,00 1,01 31,31 0,00 0,00 67,68 20:02:52 4 0,00 0,00 0,00 0,00 1,01 29,29 0,00 0,00 69,70 20:02:52 5 0,00 0,00 0,00 0,00 0,00 34,02 0,00 0,00 65,98 20:02:52 6 0,00 0,00 0,00 0,00 1,00 31,00 0,00 0,00 68,00 20:02:52 7 0,00 0,00 0,00 0,00 0,00 29,59 0,00 0,00 70,41 20:02:52 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:53 all 0,00 0,00 0,13 0,00 0,76 29,33 0,00 0,00 69,79 20:02:53 0 0,00 0,00 0,00 0,00 1,01 27,27 0,00 0,00 71,72 20:02:53 1 0,00 0,00 0,00 0,00 0,00 27,55 0,00 0,00 72,45 20:02:53 2 0,00 0,00 0,00 0,00 1,02 31,63 0,00 0,00 67,35 20:02:53 3 0,00 0,00 0,00 0,00 1,01 30,30 0,00 0,00 68,69 20:02:53 4 0,00 0,00 0,00 0,00 0,00 28,57 0,00 0,00 71,43 20:02:53 5 0,00 0,00 0,00 0,00 1,00 32,00 0,00 0,00 67,00 20:02:53 6 0,00 0,00 0,00 0,00 1,01 28,28 0,00 0,00 70,71 20:02:53 7 0,00 0,00 0,00 0,00 1,00 29,00 0,00 0,00 70,00 20:02:53 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:54 all 0,13 0,00 0,00 0,00 0,63 29,76 0,00 0,00 69,48 20:02:54 0 1,01 0,00 0,00 0,00 0,00 29,29 0,00 0,00 69,70 20:02:54 1 0,00 0,00 0,00 0,00 1,00 30,00 0,00 0,00 69,00 20:02:54 2 0,00 0,00 0,00 0,00 0,00 30,30 0,00 0,00 69,70 20:02:54 3 0,00 0,00 0,00 0,00 1,01 30,30 0,00 0,00 68,69 20:02:54 4 0,00 0,00 0,00 0,00 1,01 28,28 0,00 0,00 70,71 20:02:54 5 0,00 0,00 0,00 0,00 0,00 33,33 0,00 0,00 66,67 20:02:54 6 0,00 0,00 0,00 0,00 0,00 28,57 0,00 0,00 71,43 20:02:54 7 0,00 0,00 0,00 0,00 1,02 28,57 0,00 0,00 70,41 20:02:54 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:55 all 0,00 0,00 0,13 0,00 0,63 29,55 0,00 0,00 69,70 20:02:55 0 0,00 0,00 1,01 0,00 1,01 29,29 0,00 0,00 68,69 20:02:55 1 0,00 0,00 0,00 0,00 1,00 28,00 0,00 0,00 71,00 20:02:55 2 0,00 0,00 0,00 0,00 1,01 27,27 0,00 0,00 71,72 20:02:55 3 0,00 0,00 0,00 0,00 1,01 32,32 0,00 0,00 66,67 20:02:55 4 0,00 0,00 0,00 0,00 1,00 31,00 0,00 0,00 68,00 20:02:55 5 0,00 0,00 0,00 0,00 1,00 32,00 0,00 0,00 67,00 20:02:55 6 0,00 0,00 0,00 0,00 1,00 26,00 0,00 0,00 73,00 20:02:55 7 0,00 0,00 0,00 0,00 0,00 30,30 0,00 0,00 69,70 ^C [root@router ~]# Linux 3.6.2-1.fc16.i686 06.11.2012 _i686_ (8 CPU) 15:33:56 CPU intr/s 15:33:58 all 33778,50 15:33:58 0 4000,00 15:33:58 1 3997,50 15:33:58 2 3999,00 15:33:58 3 4633,00 15:33:58 4 4629,00 15:33:58 5 4000,00 15:33:58 6 3995,00 15:33:58 7 3997,50 15:33:58 CPU intr/s 15:34:00 all 33641,50 15:34:00 0 3997,50 15:34:00 1 3998,00 15:34:00 2 3997,50 15:34:00 3 4622,00 15:34:00 4 4648,50 15:34:00 5 3999,50 15:34:00 6 3995,50 15:34:00 7 3995,50 15:34:00 CPU intr/s 15:34:02 all 33674,50 15:34:02 0 4001,00 15:34:02 1 3996,50 15:34:02 2 3997,50 15:34:02 3 4647,00 15:34:02 4 4654,00 15:34:02 5 3999,00 15:34:02 6 3996,00 15:34:02 7 3997,50 Samples: 17K of event 'cycles', Event count (approx.): 1618677353 7,94% [kernel] [k] ipt_do_table 7,58% [kernel] [k] fib_table_lookup 5,53% [igb] [k] igb_poll 3,90% [kernel] [k] _raw_spin_lock 2,11% [igb] [k] igb_xmit_frame_ring 2,05% [sch_htb] [k] htb_dequeue 2,03% [kernel] [k] dev_queue_xmit 2,01% [cls_u32] [k] u32_classify 2,00% [kernel] [k] nf_iterate 1,46% [kernel] [k] __netif_receive_skb 1,22% [kernel] [k] build_skb 1,20% [kernel] [k] ip_route_input_noref 1,14% [kernel] [k] __slab_free 1,12% [kernel] [k] local_bh_enable 1,09% [ip_set_hash_net] [k] hash_net4_test 1,07% [kernel] [k] check_leaf 1,00% [kernel] [k] __slab_alloc.constprop.23 0,94% [kernel] [k] dev_hard_start_xmit 0,88% [kernel] [k] ip_forward 0,85% [kernel] [k] ip_rcv 0,84% [kernel] [k] inet_gro_receive 0,81% [kernel] [k] ip_finish_output 0,80% [kernel] [k] put_page 0,80% [kernel] [k] dev_gro_receive 0,78% [kernel] [k] ip_rcv_finish 0,77% [ip_set] [k] ip_set_test 0,74% perf [.] 0x0004bb19 0,70% [kernel] [k] kmem_cache_alloc 0,68% [kernel] [k] netif_skb_features 0,68% [igb] [k] igb_alloc_rx_buffers 0,68% [kernel] [k] harmonize_features 0,66% [kernel] [k] tcp_gro_receive 0,64% [kernel] [k] vlan_do_receive 0,60% [kernel] [k] ip_forward_finish 0,60% [iptable_mangle] [k] iptable_mangle_hook 0,59% [kernel] [k] __netdev_alloc_frag 0,58% [kernel] [k] _raw_read_lock_bh 0,58% [bonding] [k] bond_start_xmit 0,57% [kernel] [k] _raw_read_lock 0,56% [kernel] [k] napi_gro_receive 0,54% [kernel] [k] nommu_map_page 0,53% [kernel] [k] check_addr 0,53% [bonding] [k] bond_handle_frame 0,51% [bonding] [k] bond_3ad_xmit_xor 0,50% [nf_conntrack_ipv4] [k] ipv4_helper 0,48% [kernel] [k] skb_release_head_state 0,48% [kernel] [k] local_bh_disable 0,47% [kernel] [k] native_sched_clock 0,47% [bonding] [k] bond_xmit_hash_policy_l34 0,47% [iptable_raw] [k] iptable_raw_hook 0,47% [kernel] [k] nf_hook_slow 0,47% [kernel] [k] irq_entries_start 0,46% [kernel] [k] ktime_get 0,45% [kernel] [k] page_address 0,45% [kernel] [k] __list_del_entry 0,44% [sch_htb] [k] htb_enqueue 0,44% [nf_conntrack] [k] nf_conntrack_in 0,43% [kernel] [k] get_page_from_freelist 0,42% [iptable_nat] [k] nf_nat_in 0,41% [kernel] [k] add_interrupt_randomness 0,41% [kernel] [k] lookup_page_cgroup_used 0,41% [kernel] [k] qdisc_dequeue_head 0,40% [kernel] [k] skb_free_head 0,40% [kernel] [k] read_tsc 0,40% [kernel] [k] account_system_vtime 0,40% [kernel] [k] skb_release_data 0,38% [kernel] [k] iptable_filter_hook Press '?' for help on key bindings растолкуйте _raw_spin_lock - как я понял, это некая блокировка, скорее всего карты очередями толкаются и возможно за прерывания дерутся? После включения шейпера эта блокировка вырастает процентов на 10 в perf top. на всех сетевых картах: ethtool -G eth0 rx 4096 tx 4096 ethtool -G eth1 rx 4096 tx 4096 ethtool -G p2p1 rx 4096 tx 4096 ethtool -G p3p1 rx 4096 tx 4096 ethtool -G p3p2 rx 4096 tx 4096 ethtool -G p4p1 rx 4096 tx 4096 ethtool -C eth1 rx-usecs 1000 ethtool -C p2p1 rx-usecs 1000 ethtool -C p3p1 rx-usecs 1000 ethtool -C p3p2 rx-usecs 1000 ethtool -C p4p1 rx-usecs 1000 подбирал опытным путем, по умолчанию выставлено 3, что означает динамический консервативный режим, который выставлял мне до 300 тыс. прерываний в сек. что не есть гуд. Драйвер ядреный, igb от Intel скомпилил, но пока еще не применял - не удобно регулировать и подбирать значение ITR на лету, на работающем канале, через rmmod и modprobe. gro, tso - что выключено, что включено, особой роли не играет. на данный момент оставил включенными. ifconfig eth0 txqueuelen 10000 ifconfig eth1 txqueuelen 10000 ifconfig p2p1 txqueuelen 10000 ifconfig p3p1 txqueuelen 10000 ifconfig p3p2 txqueuelen 10000 ifconfig p4p1 txqueuelen 10000 По всем очередям/буферам, как аппаратным, так и программым перестраховался по максимуму, не знаю, может не прав, буду признателен, если укажете на ошибочность принятого мной решения. Находил здесь расхожие мнения на этот счет. То же самое про Hyper Threading, как я понял, некоторые считают, что это технология для роутинга никак не помогает, даже мало того, мешает, вымывая кеш процессора. Стоит ли оставить только 4 ядра, и по 4 очереди на сетевых картах? Правильно ли будет разделять Tx и Rx на две раздельных очереди и каждую вешать на свое прерывание или стоит их объединить? Нужно ли rx с одного интерфейса группировать с tx другого интерфейса на одном ядре процессора? Или достаточно их развести на разные ядра? До oprofile пока еще не дошел. Что касается iptables: Выключаю conntrack для своих сеток Таблица raw -A PREROUTING -s 191.21.12.0/22 -j NOTRACK -A PREROUTING -d 191.21.12.0/22 -j NOTRACK -A PREROUTING -s 146.11.40.0/21 -j NOTRACK -A PREROUTING -d 146.11.40.0/21 -j NOTRACK -A OUTPUT -s 191.21.12.0/22 -j NOTRACK -A OUTPUT -d 191.21.12.0/22 -j NOTRACK -A OUTPUT -s 146.11.40.0/21 -j NOTRACK -A OUTPUT -d 146.11.40.0/21 -j NOTRACK В INPUT набор stateless правил, что-бы ограничить доступ к роутеру. В FORWARD дроп фейковых адресов и счетчики для интересующих меня адресов. - возможно это тоже здесь лишнее и даже простой count приводит к проблемам ? -A FORWARD -s 192.168.0.0/16 -j DROP -A FORWARD -d 192.168.0.0/16 -j DROP -A FORWARD -d 191.21.12.248/29 -j customer1 -A FORWARD -s 191.21.12.248/29 -j customer1 -A FORWARD -d 191.21.12.45/32 -j customer2 -A FORWARD -s 191.21.12.45/32 -j customer2 -A FORWARD -d 191.21.12.240/29 -j customer3 -A FORWARD -s 191.21.12.240/29 -j customer3 -A FORWARD -d 146.11.40.248/29 -j customer4 -A FORWARD -s 146.11.40.248/29 -j customer4 -A FORWARD -d 146.11.40.240/29 -j customer5 -A FORWARD -s 146.11.40.240/29 -j customer5 -A FORWARD -d 146.11.40.224/30 -j customer6 -A FORWARD -s 146.11.40.224/30 -j customer6 -A FORWARD -d 146.11.40.232/30 -j customer7 -A FORWARD -s 146.11.40.232/30 -j customer7 -A FORWARD -d 146.11.40.228/30 -j customer8 -A FORWARD -s 146.11.40.228/30 -j customer8 -A FORWARD -d 146.11.40.220/30 -j customer9 -A FORWARD -s 146.11.40.220/30 -j customer9 -A FORWARD -d 146.11.40.208/30 -j customer10 -A FORWARD -s 146.11.40.208/30 -j customer10 Пробовал правила сбрасывать - разницы особой не заметил, что с правилами,что без ... Пока склоняюсь к мысли, что я подошел к верхней планке возможностей, и на скоростях выше полутора гигабит нужно забыть об использовании шейпера, и делать видимо это уже нужно не на транзитном роутере. Особенно, если ожидается раширение bond-ов, например раза в 2, пока не произойдет переход на 10G. А когда это произойдет, то в этом случае мне кажется тем более можно забыть про шейпер на PC-платформе. Или я ошибаюсь? Как может влиять bonding на сетевую производительность? Вижу выход в том, что можно увести всех небольших потребителей трафика на другой роутер, на котором собственно и строить шейпер для них. А этот роутер оставить в покое - только перекачка суммарного трафика всей сети с интерфейса в интерфейс. Прошу поделиться опытом, привести примеры, кто сколько прокачивает с включенным шейпером и какие у вас при этом настройки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 6 ноября, 2012 · Жалоба У вас фильтры простые, без хэширования, поэтому время обхода всех правил при прохождении пакета будет расти как O(N) в зависимости от числа правил. См. http://lartc.org/howto/lartc.adv-filter.hashing.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vinnipux Опубликовано 6 ноября, 2012 (изменено) · Жалоба О хешировании я в курсе, и в курсе о достаточно удобном скрипте sc, но его я пока тестирую в виртуалках и на практике не применяю. Не уверен, что в моих условиях это то, что мне нужно. Клиентов согласно тарифов я жму на брасах. Я просто пытаюсь понять - 10 правил на конкретные адреса/сетки на 4-16 адресов и одно правило для всего остального могут так влиять на пропускную способность на скорости выше 1.5Гбит? Я ведь не пытаюсь прописать тысячи правил, в которых будут перечислены каждый из 3-х тысяч моих ip-адресов ... И неужели конструкция вида /sbin/tc class add dev bond0 parent 1:2 classid 1:900 htb rate 100Mbit ceil 1950Mbit prio 1 /sbin/tc qdisc add dev bond0 parent 1:900 handle 900 pfifo limit 50000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.0/21 classid 1:900 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.0/22 classid 1:900 способна привести к такому росту затрат на проверку, одну проверку каждого пакета, ведь в данном случае по идее должна матчиться какая-то часть заголовка dst длина которого определяет маска. Может u32 match сам по себе не оптимален и не высокопроизводителен? Кроме всего прочего, правильно ли я понял прочитав кучу разных источников, что шейпер собственно в текущей его реализации не паралеллится толком, что приводит к блокировкам и эффекту бутылочного горлышка, не важно сколько у тебя очередей в картах и ядер в проце? .... Или по уму мне нужно все-таки создать описание для каждого ip-адреса из всех моих сетей, используя хеши, что породит кучу правил, пускай они будут и оптимизированные. Не усугубит ли такой вариант текущее положение? Просто на текущий момент пока все что мне нужно это отрегулировать скорость на десяток небольших сеток и обозначить некую общую скорость для всех остальных, не уточняя полосу для каждого ip из имеющегося пула, но хотелось бы. Есть сомнения, что роутер прожует это все, даже если набор правил будет оптимизирован хешами. И еще очень интересно какая у кого максимальная скорость была достигнута на роутере с включенным шейпером. Изменено 7 ноября, 2012 пользователем vinnipux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
