morfair Опубликовано 26 декабря, 2013 (изменено) · Жалоба Странность такую заметил. Когда стояла одна сетевуха, при загруженности по ~800 Мбит/сек на интерфейс проц был занят на 30-40%, а сейчас после агрегирования (layer 2+3) при трафике 300-400 Мбит/сек процессор загружен на 60%. Нехорошо и непонятно как-то... Изменено 26 декабря, 2013 пользователем morfair Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 27 декабря, 2013 · Жалоба И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 27 декабря, 2013 · Жалоба И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать? ethtool -C? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 30 декабря, 2013 · Жалоба Господа , кому не жалко , поделитесь конфигами ядра (желательно под > 3.X) которыми вы пользуетесь на на своих бордерах ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 30 декабря, 2013 · Жалоба Просмотр сообщенияmorfair (27 декабря 2013 - 15:20) писал: И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать? ethtool -C? Да, наверное. Только не совсем понятно, значения один в один совпадают, или отличаются?.. Господа , кому не жалко , поделитесь конфигами ядра (желательно под > 3.X) которыми вы пользуетесь на на своих бордерах ? Тоже очень интерессно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 30 декабря, 2013 (изменено) · Жалоба И еще, на NAS'е, который терминирует PPP (accel-ppp, PPTP + L2TP) что лучше использовать, CBQ или HTB? Приложил тот скрипт, что используется сейчас. Он нормальный, или стоит задуматься что-то переделывать? #!/bin/bash TC="/sbin/tc" DEV=$1 # Скорость физического интерфейса: IFSPEED="1Gbit" if [ -f /var/run/radattr.$1 ] then # Входящая для клиента (исходящая для сервера): DOWN=`/usr/bin/awk '/PPPD-Downstream-Speed-Limit/ {print $2}' /var/run/radattr.$1` # Исходящая для клиента (входящая для сервера): UP=`/usr/bin/awk '/PPPD-Upstream-Speed-Limit/ {print $2}' /var/run/radattr.$1` # Очищаем: $TC qdisc del dev $DEV root $TC qdisc del dev $DEV ingress if [ "$DOWN" != "0" ] ; then #~ DOWN10=`echo $DOWN/10 | bc 2>/dev/null` BURST=`echo $DOWN/20 | bc 2>/dev/null` # Создаем корневую очередь со скоростью общего входящего канала: # cbq - дисциплина обработки очереди # avpkt - средний размер пакета, для ethernet-интерфейсов можно считать его равным 1000 байт при mtu 1500 байт # bandwidth - физическая прпускная способность железки $TC qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth $IFSPEED # Создаем класс со скоростью согласно тарифу: # bounded - запрещает классу занимать свободную полосу от каналов с параметром sharing $TC class add dev $DEV parent 1: classid 1:1 cbq bandwidth $IFSPEED rate ${DOWN}kbit prio 1 allot 1514 cell 8 maxburst 6 mpu 700 avpkt 1000 bounded $TC class add dev $DEV parent 1: classid 1:2 cbq bandwidth $IFSPEED rate ${DOWN}kbit prio 2 allot 1514 cell 8 maxburst 6 mpu 700 avpkt 1000 bounded $TC class add dev $DEV parent 1: classid 1:3 cbq bandwidth $IFSPEED rate ${DOWN}kbit prio 3 allot 1514 cell 8 maxburst 6 mpu 700 avpkt 1000 bounded # Классифицируем трафик: # u32 - классификатор, позволяющий классифицировать пакеты на основании их атрибутов # match u32 x y - задаёт значение, с которым будут сравниваться биты из пакета (x) и размер блока данных (y, битовая маска), # который будет взят из пакета # # Type of Service - 0x10 minimize-delay $TC filter add dev $DEV parent 1: protocol ip prio 2 u32 match ip tos 0x10 0xff flowid 1:1 # # udp $TC filter add dev $DEV parent 1: protocol ip prio 2 u32 match ip protocol 17 0xff flowid 1:2 # # icmp $TC filter add dev $DEV parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:2 # # Тафтология, но по факту попадает под все пакеты: $TC filter add dev $DEV parent 1: protocol all u32 match u32 0 0 flowid 1:3 # Для более равномерного распределения пропускной пособностями между соединениями прицепим в классу # дисциплину обработки очереди SFQ: # perturb - этот параметр задает интервал в секундах, через который происходит изменение функции $TC qdisc add dev $DEV parent 1:1 sfq perturb 10 $TC qdisc add dev $DEV parent 1:2 sfq perturb 10 $TC qdisc add dev $DEV parent 1:3 sfq perturb 10 fi if [ "$UP" != "0" ] ; then BURST=`echo $UP/20 | bc 2>/dev/null` # Корневой класс исходящщего канала: $TC qdisc add dev $DEV handle ffff: ingress # Этот фильтр контролирует резкое увеличение трафика #~ $TC filter add dev $DEV parent ffff: protocol all u32 match ip src 0.0.0.0/0 police rate ${SPEED}kbit burst ${BURST}k mtu 1496 drop flowid :1 $TC filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${UP}kbit burst ${BURST}k mtu 1496 drop flowid :1 #~ $TC filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${UP}kbit burst ${BURST}k mtu 1396 drop flowid :1 fi fi Изменено 30 декабря, 2013 пользователем morfair Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 7 января, 2014 (изменено) · Жалоба Обнаружил странное поведение IPOE-BRASа на linux. 'Медленный' доступ к интерфейсам, не знаю как это еще назвать. Пример: [root@ipoe1 ~]# time ip link show eth0 2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1504 qdisc mq master bond0 state UP qlen 10000 link/ether 68:b5:99:6b:be:54 brd ff:ff:ff:ff:ff:ff real 0m0.181s user 0m0.070s sys 0m0.100s То же самое происходит с любой командой опрашивающей любые интерфейсы, ifconfig eth0 точно так же тупит. Такая банальная и по идее мгновенная команда выполняется как я понимаю целых 200мс. На соседних pppoe-BRASах такого нет, время зависит сугубо от загрузки сервера и колеблется от 0 до 10мс. Сервер HP DL380 G6, CPU L5639(6 core), загрузка выше 30% не поднимается. Поднято ~3750qiniq vlan(IPOE vlan-per-user). Из-за такого поведения процедура рестарта шейперов(запускается пакетный файл с несколькими тысячами записей) происходит не 5 секунд как на соседних pppoe-теминаторах, а 5-10 минут. Да и создание-удаление вланов происходит крайне странно - вланы поднимаются мгновенно, но в процессах потом висит куча ifup/ifconfig скриптов, отрабатывающих несколько часов. Поправил отключением автоконфигурации, но это тоже костыль. Что может вызывать такие чудеса? Сами сетевки BCM5709 с bnx2 могут чудить? Изменено 7 января, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 7 января, 2014 · Жалоба Могут, по идее можно perf/oprofile запустить и посмотреть кто тормозит. Еще сравнить версии ядер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 7 января, 2014 (изменено) · Жалоба На сервере ядро 3.10.4, пробовал 3.10.23 - разницы нет. На соседнем сервере с тем же ядром чудес нет, но там и трафика нет, сложно сравнивать. Кстати о загрузке. Сервер занимается тупой маршрутизацией + proxy arp для кучи вланов. Трафик 900M in/500M out. Ната нет, фаервола нет(десяток правил), весь трафик идет мимо контрака. top top - 19:57:38 up 11 days, 7:19, 1 user, load average: 0.12, 0.29, 0.43 Tasks: 124 total, 2 running, 122 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 2.7%sy, 0.0%ni, 68.3%id, 0.0%wa, 0.0%hi, 29.0%si, 0.0%st Cpu1 : 3.1%us, 4.1%sy, 0.0%ni, 61.0%id, 0.0%wa, 0.0%hi, 31.8%si, 0.0%st Cpu2 : 1.6%us, 2.2%sy, 0.0%ni, 69.9%id, 0.0%wa, 0.0%hi, 26.2%si, 0.0%st Cpu3 : 1.1%us, 1.6%sy, 0.0%ni, 66.5%id, 0.0%wa, 0.0%hi, 30.8%si, 0.0%st Cpu4 : 1.7%us, 2.2%sy, 0.0%ni, 70.8%id, 0.0%wa, 0.0%hi, 25.3%si, 0.0%st Cpu5 : 2.2%us, 3.3%sy, 0.0%ni, 63.9%id, 0.0%wa, 0.0%hi, 30.6%si, 0.0%st Mem: 6105300k total, 2210352k used, 3894948k free, 269288k buffers Swap: 8191992k total, 0k used, 8191992k free, 1119484k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27641 root 20 0 2086m 54m 1928 S 25.9 0.9 3460:24 accel-pppd 1913 named 20 0 555m 225m 3040 S 6.0 3.8 636:01.67 named 19 root 20 0 0 0 0 R 1.0 0.0 43:56.44 ksoftirqd/3 27 root 20 0 0 0 0 S 1.0 0.0 37:04.46 ksoftirqd/5 3 root 20 0 0 0 0 S 0.5 0.0 39:16.86 ksoftirqd/0 11 root 20 0 0 0 0 S 0.5 0.0 37:57.33 ksoftirqd/1 15 root 20 0 0 0 0 S 0.5 0.0 37:54.56 ksoftirqd/2 23 root 20 0 0 0 0 S 0.5 0.0 37:15.17 ksoftirqd/4 Откуда загрузка в 30% на ядро? Трафик ведь смешной. Такими темпами сервер долго не проживет :) Perf top ничего не говорит вообще, по идее со стороны ядра все нормально и красиво. 6.49% [kernel] [k] _raw_spin_lock 3.12% [ip_tables] [k] ipt_do_table 2.42% [kernel] [k] __netif_receive_skb_core 2.18% [kernel] [k] _raw_spin_unlock_irqrestore 2.00% [bnx2] [k] bnx2_rx_int 1.98% [cls_u32] [k] u32_classify 1.78% [kernel] [k] dev_queue_xmit 1.65% [kernel] [k] fib_table_lookup 1.63% [kernel] [k] __copy_skb_header 1.54% [kernel] [k] __napi_complete 1.37% [kernel] [k] menu_select 1.32% [kernel] [k] nf_iterate 1.31% [sch_htb] [k] htb_dequeue 1.31% [kernel] [k] irq_entries_start 1.18% [bnx2] [k] bnx2_start_xmit 1.17% [kernel] [k] vlan_do_receive 1.15% [ipoe] [k] 0x00000000000002bd 1.12% [kernel] [k] ip_finish_output 1.04% [kernel] [k] kmem_cache_free 0.96% [sch_htb] [k] htb_classify Oprofile говорит загадками, грузит "no-vmlinux" [root@ipoe1 boot]# opreport CPU: Intel Westmere microarchitecture, speed 2132.8 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 CPU_CLK_UNHALT...| samples| %| ------------------ 22780180 76.8029 no-vmlinux 5103632 17.2068 vmlinux 251231 0.8470 sch_htb 207678 0.7002 libpthread-2.12.so 206223 0.6953 bnx2 160930 0.5426 libtriton.so 124581 0.4200 ip_tables 103904 0.3503 libdns.so.81.4.1 90454 0.3050 cls_u32 Как еще можно найти корни зла? Изменено 7 января, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 8 января, 2014 · Жалоба Что может вызывать такие чудеса? Сами сетевки BCM5709 с bnx2 могут чудить? Действительно, надо бы попробовать с интеловскими сетевухами для начала. p.s. не забудьте скачать свежие дрова и компилить с опциями, которые в реадми указаны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 8 января, 2014 · Жалоба kayot что со "стандартными" вещами - intel-idle и виртуализацией VT-d? CONFIG_SYSCTL_SYSCALL_CHECK не включено ли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 января, 2014 · Жалоба vitalyb CONFIG_SYSCTL_SYSCALL_CHECK нет. Виртуализация и vt-d выключены. Вот intel-idle в linux не выключал, но не верю что он может давать такие эффекты, да и похоже он на уровне биоса выключен(в топах его нет). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 8 января, 2014 · Жалоба в топах его нет На этот счет у них там цензура что idle'ит видно в dmesg Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 8 января, 2014 · Жалоба vitalyb Вот жуки. Да, в dmesg есть строка про загрузку модуля. Как время будет ребутну машину, intel_idle.max_cstate=0 и processor.max_cstate=1 давно прописаны но как-то не было повода сервер ребутить) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 9 января, 2014 (изменено) · Жалоба Кто-нибудь уже испытал ядрышко 3.12.4?? Есть ли смысл ставить в бой??? 3.12.0/1/2/3 в неведомый момент (в моем конкретном случае не так часто - раз в 1-2 недели) вылетают с ошибкой распределения памяти для conntrack при conntrack_count ~130k. В остальном вроде бы едет. 3.12.0/1 NAT, трафик ~700Kpps, ~4Гбит, ~789K Conntrack count. (рабочая нагрузка в чнн, во время теста было в 2 раза больше, но там уперлись в процессор, но работало [сейчас они работают парами]) 3.12.1-gentoo #3 SMP Tue Nov 26 15:08:22 YEKT 2013 x86_64 Intel(R) Xeon(R) CPU X3440 @ 2.53GHz GenuineIntel GNU/Linux Пока ни разу не вылетало... Изменено 9 января, 2014 пользователем Tamahome Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 9 января, 2014 · Жалоба Вот жуки. Да, в dmesg есть строка про загрузку модуля. Как время будет ребутну машину, intel_idle.max_cstate=0 и processor.max_cstate=1 давно прописаны но как-то не было повода сервер ребутить) именно модуля? Параметры ядра на модули обычно не распространяются, а если оно в ядре, то указаных параметров должно хватить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 января, 2014 (изменено) · Жалоба Перегрузил сервер добавив intel_idle.max_cstate=0, многое ранее тайное стало явным :) Я уже год не могу понять, почему при выставленном в биосе профиле "static max performance"(отключает все энергосберегайки и acpi) сервер у меня все равно уходил в c-state и игрался частотой. Оказывается всем заведует проклятый модуль, и чихать ему на настройки сервера и ОС. Система стала работать шустрее, но чудеса не исчезли. UPD: проверил поведение сервера с большим числом вланов на 2 платформах и разных версиях ядер - похоже это нормальное состояние, так и должно быть. Буду оптимизировать софт. Изменено 15 января, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 15 января, 2014 · Жалоба kayot ЕМНИП там не так давно переделывали, и теперь вместо одного большого списка интерфейсов там хеш то ли на 8, то ли на 16 (define в исходниках) по айдишнику, соответственно средний поиск по имени = кол-во интерфейсов/2, поиск по ид - кол-во интерфейсов/16 (или 32). Могу ошибаться, пишу по памяти. А для чего нужно делать много ip link show eth0, что время выполнения критично? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 января, 2014 (изменено) · Жалоба vitalyb ip link show я привел как самую простую команду подверженную тому же эффекту. Используется развесистый HTB-шейпер, загружается в batch режиме из 2 файликов. [root@ipoe1 shaper]# cat shaper_cache_start-bond0.2 | wc -l 13439 [root@ipoe1 shaper]# cat shaper_cache_start-bond1 | wc -l 4228 На pppoe-БРАСах эти скрипты выполняются 10-20 секунд, а на IPOE с кучей вланов - 5 минут. А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным. Изменено 15 января, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 15 января, 2014 · Жалоба На pppoe-БРАСах эти скрипты выполняются 10-20 секунд, а на IPOE с кучей вланов - 5 минут. А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным. Не перезагружайте шейпер в ЧНН :) У меня тоже так, грузится и дольше, бывает, и ниче.... Но мысль по поводу связи "времени имени интерфейса" с временем загрузки правил интересная, можно глянуть как ip/tc организовано (что передается в ядро - наверняка индекс интерфейса, который предварительно определяется из имени системным вызовом) и, особенно, есть ли там кеш. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 15 января, 2014 · Жалоба На pppoe-БРАСах эти скрипты выполняются 10-20 секунд, а на IPOE с кучей вланов - 5 минут. А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным. Какой смысл перезаливать все правила раз в час? У нас написано небольшое приложение, которое держит в памяти все соответствия пользователь-шейп и при изменениях дергает соответствующие скрипты на исправление шейпов. Приличное время занимает только начальный старт (большую часть из которого занимает составление batch файла), последующие операции проходят практически моментально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 января, 2014 · Жалоба legioner0 Так сложилось исторически :) Биллинг не использует каких-либо событий и управления NASами, а просто генерирует раз в час полный список шейперов и правил доступа, и скармливает всем серверам. Не красиво, но просто и надежно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 15 января, 2014 · Жалоба legioner0 Так сложилось исторически :) Биллинг не использует каких-либо событий и управления NASами, а просто генерирует раз в час полный список шейперов и правил доступа, и скармливает всем серверам. Не красиво, но просто и надежно. У нас так же было, пока продавали интернет через vpn. Вместе с переходом на NASы пришлось программистам переделать биллинг на события Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 15 января, 2014 · Жалоба Перегрузил сервер добавив intel_idle.max_cstate=0, многое ранее тайное стало явным :) Я уже год не могу понять, почему при выставленном в биосе профиле "static max performance"(отключает все энергосберегайки и acpi) сервер у меня все равно уходил в c-state и игрался частотой. Это возможно не всё! http://stackoverflow.com/questions/12111954/context-switches-much-slower-in-new-linux-kernels Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 17 января, 2014 · Жалоба Не перестаю узнавать что-то новое из этой темы :) Это возможно не всё! http://stackoverflow...w-linux-kernels Спасибо. Я оптимизировал iptables, изучал flame graph системный вызовов (уже тогда обратил внимание на intel_idle, но не придал этому значения), собранных с помощью perf, пересобирал десятки раз ядро, настраивал параметры napi, оптимизировал шейпер... а после этого сообщения запустил утилиту i7z и узнал, что у меня на бордерах и насах процессоры уходят в сон :). Даже в голову не приходило проверить частоту процессора, после настроек в биосе. Не думаю, что отключение энергосбережения сильно поможет, но все равно - слона то я и не заметил. Линукс негодяй, оказывается ему пофиг на настройки в биосе (тоже везде стоит "static max performance"). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...