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

replicant

Активный участник
  • Публикации

    349
  • Зарегистрирован

  • Посещение

О replicant

  • Звание
    Студент

Посетители профиля

920 просмотров профиля
  1. accel pptpd

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

    Обновился до 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 было точно так же.
  3. accel pptpd

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

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

    В 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 было бы интересно узнать.
  6. Указание параметров ядра решает и вопросы с частотой. 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
  7. Т.е. я правильно понял что надо выкосить из ядра вот это 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 получается.
  8. С этим согласен, но пока искал причину, то пришлось уменьшить до RSS=2,2, вместо 4,4.
  9. Все разобрался. Слона-то и не заметил. Причиной был подгрузившийся модуль NF_CONNTRACK_PPTP. После выгрузки все нормализовалось. Нагрузка на CPU железяки при пролетающих через нее суммарно 1.5 Гбит/с трафика теперь около 2.5-3.5%. Так и должно быть. Соответственно все остальные риторические вопросы тоже отпали сами собой.
  10. Такое чувство, что сервак что-то пытается сделать с пролетающими через него pptp туннелями, но зачем? Откуда ноги у gre_pkt_to_tuple ?
  11. Когда поставили 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
  12. У меня 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
  13. ЧАСТЬ 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 глючной попался? Никто не сталкивался с подобным?
  14. Как минимум отказаться от 2.6.32.x и собрать на 3.2.55. Тоже были косяки с ребутами, но после выхода 3.2.х и перехода на эту ветку просто все ушло. Разбираться уже заломало и года два сидим на 3.2.х плотно. Задачи аналогичные - нат, шейпинг и т.п. И началось тоже внезапно.