replicant

+1

Сижу всем зоопарком на 3.2.х ветке ванильных ядер с самого момента её появления и до сих пор с разработанными конфигами для собственных нужд и слезать не собираюсь даже тогда, когда на неё задвинут разработчики и когда её не будут поддерживать. Любые попытки соскочить с этой ветви приводили к дестабилизации работы в том или ином виде. Ядра ветви 3.2.х пока юзаю разные (55, 64, 72, вчерась поставил где-то 73-е), в зависимости от ленивости. Где-то обновлял год или более назад, а где-то месяц или менее. Чисто под настроение. Глобальные обновления ядра со сменой ветви например с 3.2.х на 4.1.х или даже что-то новее на серверах авторизации считаю не особо нужными, когда там ничего кроме самой тупой авторизации и нет. Ходят себе годами туда-сюда туннели поднимают и опускают вместе с шейперами. Ну пусть этим и дальше занимаются. Апдейт ядра - это дело больше сугубо личное, чем реально необходимое. Админ хоть и технарь, но существу суеверное иногда. Лично я верю в кармическую чистоту 3.2.х. Она себя зарекомендовала.

Обновился до 1.7.4 (я так понимаю теперь /lib можно убить, а /lib64 теперь вместо него). До этого стояла версия 1.7.3 на 64 битной системе. Однако в логах ошибка так и не пропала. В связи с чем связано попадание вот этого в лог? Такая строка падает в лог, если пользователь указал любой несуществующий логин. [2014-05-29 13:34:27]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:34:29]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:34:29]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:34:30]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:34]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:36]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:34:37]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:34:37]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:34:37]: warn: ppp170: mschap-v2: user not found [2014-05-29 13:34:42]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:44]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:34:44]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:34:44]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:34:47]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:49]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:34:51]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:51]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:34:52]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:34:56]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:34:56]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:34:58]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:34:58]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:34:59]: warn: ppp170: mschap-v2: user not found [2014-05-29 13:35:03]: warn: ppp161: mschap-v2: user not found [2014-05-29 13:35:05]: warn: ppp166: mschap-v2: user not found [2014-05-29 13:35:05]: warn: ppp167: mschap-v2: user not found [2014-05-29 13:35:06]: warn: ppp168: mschap-v2: user not found [2014-05-29 13:35:06]: warn: ppp161: mschap-v2: user not found При этом авторизация у правильных проходит нормально и такой строки они не создают. Все работает, а лог продолжает заваливаться мусором. В 1.7.3 было точно так же.

Я бы рад, но у меня это не работает. Пусто. В чем причина не могу найти. Приноровился выдергивать уже из accel-cmd.

Мне технически было бы проще выдернуть ее так как это предполагается в auth-up #!/usr/bin/perl # скрипт auth-up $username = $ARGV[1]; А как узнать уже в установленной сессии по номеру pppX какой логин был использован кроме как через accel-cmd? Т.е. как мне найти соответствие ppp и логина другим способом? Тут я чего-то затупил...

В man pppd есть упоминание auth-up сценария Если я добавлю в конфиг accel в секцию к ip-up отсыл еще и к auth-up, то он его поймет или нет? Или чтобы вытащить имя пользователя лучше собрать версию с поддержкой accel-cmd и выдергивать через ip-up с помощью accel-cmd show sessions | grep pppX (речь идет о версии без поддержки radius, т.к. с ним все понятно как делать)? Т.е. мне просто надо в логи в БД через ip-up положить логин, под которым вошел клиент. ------------------- UPD: уже прикрутил кусок кода про accel-cmd и собрал с ним, но все же про auth-up было бы интересно узнать.

Указание параметров ядра решает и вопросы с частотой. powertop говорит Package | Core | CPU 0 | | C0 active inf% C2 (pc2) 0.0% | | C3 (pc3) 0.0% | C3 (cc3) 0.0% | C6 (pc6) 0.0% | C6 (cc6) 0.0% | C7 (pc7) 0.0% | C7 (cc7) 0.0% | | Core | CPU 1 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | | Core | CPU 2 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | | Core | CPU 3 | | C0 active inf% | | | C3 (cc3) 0.0% | | C6 (cc6) 0.0% | | C7 (cc7) 0.0% | Т.е. состояния С2,C3,C6,C7 не используются. А дальше показывает, что Package | Core | CPU 0 | | Actual 0 Idle 100.0% | Idle 100.0% | Idle 100.0% | Core | CPU 1 | | Actual 0 | Idle 100.0% | Idle 100.0% | Core | CPU 2 | | Actual 0 | Idle 100.0% | Idle 100.0% | Core | CPU 3 | | Actual 0 | Idle 100.0% | Idle 100.0% частота 100% и больше нет смысла выводить показатель Actual в GHz. В perf top появился irq_entries_start, которого раньше не было. Ну и при RSS=4,4 нагрузка на si стала чуть больше. samples pcnt kernel function _______ _____ _______________ 7203.00 - 11.9% : irq_entries_start 6276.00 - 10.4% : ixgbe_poll [ixgbe] 4758.00 - 7.9% : ipt_do_table 2332.00 - 3.9% : add_interrupt_randomness 2040.00 - 3.4% : _raw_spin_lock 1530.00 - 2.5% : nf_iterate 1385.00 - 2.3% : ixgbe_xmit_frame_ring [ixgbe] 1054.00 - 1.7% : dev_queue_xmit 1025.00 - 1.7% : ip_route_input_common 922.00 - 1.5% : rcu_enter_nohz 879.00 - 1.5% : ____nf_conntrack_find 862.00 - 1.4% : eth_type_trans 851.00 - 1.4% : local_bh_enable 766.00 - 1.3% : __napi_complete 666.00 - 1.1% : tick_nohz_stop_sched_tick

Т.е. я правильно понял что надо выкосить из ядра вот это CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_INTEL_IDLE=y А также в lilo (у меня он загрузчиком стоит) прописать эти две строки? intel_idle.max_cstate=0 processor.max_cstate=1 -------------------------------- В принципе powertop показывает что частота гуляет в пределах от 2.8 до 3.4 ГГц, поэтому не критично, хотя и неприятно с этим idle получается.

С этим согласен, но пока искал причину, то пришлось уменьшить до RSS=2,2, вместо 4,4.

Все разобрался. Слона-то и не заметил. Причиной был подгрузившийся модуль NF_CONNTRACK_PPTP. После выгрузки все нормализовалось. Нагрузка на CPU железяки при пролетающих через нее суммарно 1.5 Гбит/с трафика теперь около 2.5-3.5%. Так и должно быть. Соответственно все остальные риторические вопросы тоже отпали сами собой.

Такое чувство, что сервак что-то пытается сделать с пролетающими через него pptp туннелями, но зачем? Откуда ноги у gre_pkt_to_tuple ?

Когда поставили ixgbe, то стало так PerfTop: 23194 irqs/sec kernel:99.8% [100000 cycles], (all, 4 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 133504.00 - 38.4% : gre_pkt_to_tuple 130579.00 - 37.5% : memcmp 11445.00 - 3.3% : intel_idle 7069.00 - 2.0% : ixgbe_poll [ixgbe] 7041.00 - 2.0% : ipt_do_table 2335.00 - 0.7% : nf_iterate 2334.00 - 0.7% : _raw_spin_lock 2330.00 - 0.7% : ip_route_input_common 2170.00 - 0.6% : __slab_free 2157.00 - 0.6% : ixgbe_xmit_frame_ring [ixgbe] 1687.00 - 0.5% : ____nf_conntrack_find 1637.00 - 0.5% : dev_queue_xmit 1605.00 - 0.5% : irq_entries_start 1450.00 - 0.4% : eth_type_trans 1050.00 - 0.3% : vlan_do_receive ================= пока стояли igb картинка была такой, т.е. никакого to_tuple не было в помине ... PerfTop: 8142 irqs/sec kernel:99.2% [100000 cycles], (all, 4 CPUs) ------------------------------------------------------------------------------ samples pcnt kernel function _______ _____ _______________ 12096.00 - 10.1% : igb_poll [igb] 10523.00 - 8.8% : intel_idle 6675.00 - 5.6% : ipt_do_table 5089.00 - 4.2% : __memcpy 4265.00 - 3.6% : _raw_spin_lock 4022.00 - 3.3% : irq_entries_start 2741.00 - 2.3% : __slab_free 2190.00 - 1.8% : nf_iterate 1939.00 - 1.6% : dev_queue_xmit 1784.00 - 1.5% : __napi_complete 1773.00 - 1.5% : igb_xmit_frame_ring [igb] 1653.00 - 1.4% : rcu_enter_nohz 1629.00 - 1.4% : ____nf_conntrack_find 1567.00 - 1.3% : __slab_alloc.constprop.69 1546.00 - 1.3% : ksize

У меня 4 ядра Xeon E3 1240v2 -3.4 GHz без HT, поэтому мне не надо 8 очередей. У меня по две комбинированные очереди на порт 10Г. Соответственно загружаю драйвер с опциями /sbin/modprobe ixgbe IntMode=2,2 RSS=2,2 DCA=2,2 LRO=0,0 Далее просто прибиваю очереди к ядрами типа так echo 1 > /proc/irq/42/smp_affinity echo 2 > /proc/irq/43/smp_affinity echo 4 > /proc/irq/45/smp_affinity echo 8 > /proc/irq/46/smp_affinity Что значит отсутствует распределение по очередям? В cat /proc/interrupts четко видны очереди по две на каждый порт 10Г прибитые к ядрам. 42: 35332028 2 2 1 PCI-MSI-edge eth0-TxRx-0 43: 3 30171958 0 3 PCI-MSI-edge eth0-TxRx-1 45: 2 0 39410653 2 PCI-MSI-edge eth1-TxRx-0 46: 1 3 0 37290726 PCI-MSI-edge eth1-TxRx-1

ЧАСТЬ 1: Имеется Intel 82599EB и два способа отключения LRO. 1. modprobe ixgbe LRO=0 2. ethtool -K eth0 lro off Какой способ правильный и идет ли речь об одном и том же параметре LRO или это все же разные опции? --------- ЧАСТЬ 2: При использовании сервера в качестве L3 routing машины надо ли отключать опции ethtool -K gro, gso, tso, lro или пофиг (раньше отключал)? --------- ЧАСТЬ 3: При переходе с двух 4-х портовых 82576 на одну 82599 резко возросла нагрузка на CPU вплоть до 100% загрузки на ровном месте. Ничего не менялось, кроме вытаскивания одной железки и втыкания другой в ту же самую машину, ну и соответственно сборки другого драйвера. Собрал 3.19.1, хотя ядерный был 3.6.7. С чего бы вдруг случилось такое поведение машины? Может 3.19.1 глючной попался? Никто не сталкивался с подобным?

Как минимум отказаться от 2.6.32.x и собрать на 3.2.55. Тоже были косяки с ребутами, но после выхода 3.2.х и перехода на эту ветку просто все ушло. Разбираться уже заломало и года два сидим на 3.2.х плотно. Задачи аналогичные - нат, шейпинг и т.п. И началось тоже внезапно.

Двухкратным запасом по пропускной способности. На практике это и будет лучший QoS. А вообще, если канал очень узкий и его не хватает на всех (вроде бы речь о 10Мбит/с), то танцы с бубном могут и не помочь. Допустим удастся сделать красивый "пинг" через приоритеты и т.п., а толку? Остальной трафик как шел еле-еле, так и пойдет.

Это все понятно, но в dmesg неприятно. В любом случае я уже разобрался и теперь все красиво. Причина лишь в том что r2q для ppp и для ifb в разных местах указывается.

В итоге решил сделать так (пока по идиотски, но работает): стартую аксель, он добавляет такую строку (видно ее в tc qdisc show dev ifb0) tc qdisc add dev ifb0 root handle 1: htb default 0 r2q 10 я ее прибиваю tc qdisc del dev ifb0 root handle 1: htb default 0 r2q 10 и тут же стартую с r2q 1500, а только потом разрешаю юзерам коннекты к 1723 порту, чтобы не создавали туннели раньше времени пока на ifb0 ничего в tc не повисло после этого в dmesg тишина -------------------------- Также пересобрал изменив в shaper.c r2q=1000 ... вроде бы стало нормально. Было бы роскошно, если бы xeb вынес r2q для ifb тоже в конфиг, чтобы не мучать исходник. quantum для разных скоростей выглядит при r2q=1000 так class htb 1:22 root prio 0 quantum 7860 rate 62880Kbit ceil 62880Kbit burst 62880b/8 mpu 0b overhead 0b cburst 153387b/8 mpu 0b overhead 0b level 0 class htb 1:23 root prio 0 quantum 5240 rate 41920Kbit ceil 41920Kbit burst 41920b/8 mpu 0b overhead 0b cburst 153390b/8 mpu 0b overhead 0b level 0 class htb 1:27 root prio 0 quantum 10480 rate 83840Kbit ceil 83840Kbit burst 83840b/8 mpu 0b overhead 0b cburst 153385b/8 mpu 0b overhead 0b level 0 class htb 1:24 root prio 0 quantum 13100 rate 104800Kbit ceil 104800Kbit burst 104800b/8 mpu 0b overhead 0b cburst 153374b/8 mpu 0b overhead 0b level 0 class htb 1:25 root prio 0 quantum 2620 rate 20960Kbit ceil 20960Kbit burst 20960b/8 mpu 0b overhead 0b cburst 153395b/8 mpu 0b overhead 0b level 0 Соответственно и tc -s qdisc sh dev ifb0 qdisc htb 1: root refcnt 2 r2q 1000 default 0 direct_packets_stat 0 Теперь dmesg молчит как и должен, т.к. quantum в порядке. Если разброс скоростей по тарифам большой, то красоту наводить немного сложнее. Надо просто точнее считать. Т.е. если есть 100 Мбит/с и 2 Мбит/с, то будет ловить либо small, либо big, если юзать htb средствами accel-ppp. Разброс не более чем 40 раз в пределах диапазона допустимых значений quantum.

kayot, а как же рекомендации к 1500 < quantum < 60000 ? В accel-ppp.conf ставится r2q и quantum, но это касается только pppX, а на ifb это не распространяется. Для ifb это где-то в другом месте изменяется. Возможно в исходниках в shaper.c, но не уверен что так будет правильно. Именно ifb источник сообщений в dmesg. Теоретически можно забить на dmesg, но неприятно.

Тут другая засада вылезает. Расчет показывает оптимальный r2q в диапазоне от 1000 до 1700, я ставлю 1500. Тогда quantum красивый, но мессаджи все равно ползут из-за вот этого qdisc htb 1: dev ifb0 root refcnt 2 r2q 10 default 0 direct_packets_stat 0 - тут не красиво с r2q qdisc htb 1: dev ppp0 root refcnt 2 r2q 1500 default 1 direct_packets_stat 0 - тут все красиво т.е. на ifb0 r2q=10, т.е. по-дефолту. Вот его ХЗ где изменить. Явно где-то не в accel-ppp.conf Даже, если я закомментирую в accel-ppp.conf параметр r2q, а quantum сделаю =65535, то все равно r2q на ifb0 будет =10. Отдельного скрипта для шейпера нет. Шейплю средствами accel.

Попробую посидеть с калькулятором. Разброс скоростей всего в 5 раз от 20 Мбит до 100 Мбит. Хотя и при таких настройках шейпит все красиво и правильно.

[shaper] vendor=Cisco attr=Cisco-AVPair up-limiter=htb down-limiter=htb cburst=153400 ifb=ifb0 r2q=10 quantum=1500 verbose=0 down-burst-factor=0.1 up-burst-factor=1.0 В dmesg валится примерно такое [ 996.498553] HTB: quantum of class 10001 is big. Consider r2q change. [ 996.498578] HTB: quantum of class 1001A is big. Consider r2q change. [ 1059.947421] HTB: quantum of class 10001 is big. Consider r2q change. [ 1059.947445] HTB: quantum of class 1001B is big. Consider r2q change. [ 1088.011856] HTB: quantum of class 10001 is big. Consider r2q change. Как это отключить? Уменьшить quantum (MTU на туннелях 1400) или где-то в другом месте (r2q) подкрутить? Скорости такого порядка class htb 1:35 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b class htb 1:34 root prio 0 rate 104800Kbit ceil 104800Kbit burst 104800b cburst 153374b class htb 1:3b root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b class htb 1:3a root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b class htb 1:39 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b class htb 1:38 root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b class htb 1:3f root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b class htb 1:3e root prio 0 rate 41920Kbit ceil 41920Kbit burst 41920b cburst 153390b class htb 1:3d root prio 0 rate 20960Kbit ceil 20960Kbit burst 20960b cburst 153395b class htb 1:3c root prio 0 rate 62880Kbit ceil 62880Kbit burst 62880b cburst 153387b

Насколько опасны ворнинги при сборке версии 1.7.3? Ядро 3.2.54. Scanning dependencies of target radius [ 54%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/stat_accm.c.o [ 56%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/dict.c.o [ 57%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/req.c.o [ 58%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/packet.c.o [ 60%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/auth.c.o [ 61%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/acct.c.o [ 62%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/serv.c.o /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c: In function 'load_config': /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:394:33: warning: 'acct_secret' may be used uninitialized in this function [-Wmaybe-uninitialized] /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:366:8: note: 'acct_secret' was declared here /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:395:16: warning: 'acct_port' may be used uninitialized in this function [-Wmaybe-uninitialized] /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:365:6: note: 'acct_port' was declared here /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:391:15: warning: 'auth_port' may be used uninitialized in this function [-Wmaybe-uninitialized] /usr/src/accel-ppp-1.7.3/accel-pppd/radius/serv.c:362:6: note: 'auth_port' was declared here [ 64%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/dm_coa.c.o /usr/src/accel-ppp-1.7.3/accel-pppd/radius/dm_coa.c: In function 'coa_request': /usr/src/accel-ppp-1.7.3/accel-pppd/radius/dm_coa.c:180:7: warning: 'prev_class' may be used uninitialized in this function [-Wmaybe-uninitialized] [ 65%] Building C object accel-pppd/radius/CMakeFiles/radius.dir/radius.c.o Linking C shared library libradius.so [ 65%] Built target radius И можно ли как-то этого избежать?

Не всякий L3 коммутатор на роли шлюза справится с 8-10 тыс. связок ip-mac клиентов, которые надо тупо роутить в разные стороны. И дело даже не в трафике, а в кол-ве этих самых маршрутов, с которыми приходится иметь дело.

Скорее интересует не само 3.9.х ядро, а с какого именно на него перешли? Не думаю что при переходе с 3.2.44 или 3.4.45 будет подобный прирост и будет ли вообще.