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

Странность такую заметил. Когда стояла одна сетевуха, при загруженности по ~800 Мбит/сек на интерфейс проц был занят на 30-40%, а сейчас после агрегирования (layer 2+3) при трафике 300-400 Мбит/сек процессор загружен на 60%. Нехорошо и непонятно как-то...

Изменено пользователем morfair

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать?

 

ethtool -C?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Господа , кому не жалко , поделитесь конфигами ядра (желательно под > 3.X) которыми вы пользуетесь на на своих бордерах ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Просмотр сообщенияmorfair (27 декабря 2013 - 15:20) писал:

И еще, подскажите, можно ли InterruptThrottleRate менять на ходу или обязательно модуль выгружать?

 

 

ethtool -C?

Да, наверное. Только не совсем понятно, значения один в один совпадают, или отличаются?..

 

Господа , кому не жалко , поделитесь конфигами ядра (желательно под > 3.X) которыми вы пользуетесь на на своих бордерах ?

Тоже очень интерессно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще, на 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

Изменено пользователем morfair

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обнаружил странное поведение 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 могут чудить?

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Могут, по идее можно perf/oprofile запустить и посмотреть кто тормозит.

Еще сравнить версии ядер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На сервере ядро 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

 

Как еще можно найти корни зла?

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что может вызывать такие чудеса? Сами сетевки BCM5709 с bnx2 могут чудить?

Действительно, надо бы попробовать с интеловскими сетевухами для начала.

 

p.s. не забудьте скачать свежие дрова и компилить с опциями, которые в реадми указаны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kayot

что со "стандартными" вещами - intel-idle и виртуализацией VT-d?

 

CONFIG_SYSCTL_SYSCALL_CHECK не включено ли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vitalyb

CONFIG_SYSCTL_SYSCALL_CHECK нет.

Виртуализация и vt-d выключены.

Вот intel-idle в linux не выключал, но не верю что он может давать такие эффекты, да и похоже он на уровне биоса выключен(в топах его нет).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в топах его нет

На этот счет у них там цензура

 

что idle'ит видно в dmesg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vitalyb

Вот жуки. Да, в dmesg есть строка про загрузку модуля.

Как время будет ребутну машину, intel_idle.max_cstate=0 и processor.max_cstate=1 давно прописаны но как-то не было повода сервер ребутить)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто-нибудь уже испытал ядрышко 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

 

Пока ни разу не вылетало...

Изменено пользователем Tamahome

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Вот жуки. Да, в dmesg есть строка про загрузку модуля.

Как время будет ребутну машину, intel_idle.max_cstate=0 и processor.max_cstate=1 давно прописаны но как-то не было повода сервер ребутить)

именно модуля? Параметры ядра на модули обычно не распространяются, а если оно в ядре, то указаных параметров должно хватить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перегрузил сервер добавив intel_idle.max_cstate=0, многое ранее тайное стало явным :)

Я уже год не могу понять, почему при выставленном в биосе профиле "static max performance"(отключает все энергосберегайки и acpi) сервер у меня все равно уходил в c-state и игрался частотой.

Оказывается всем заведует проклятый модуль, и чихать ему на настройки сервера и ОС.

Система стала работать шустрее, но чудеса не исчезли.

 

UPD: проверил поведение сервера с большим числом вланов на 2 платформах и разных версиях ядер - похоже это нормальное состояние, так и должно быть.

Буду оптимизировать софт.

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

kayot

ЕМНИП там не так давно переделывали, и теперь вместо одного большого списка интерфейсов там хеш то ли на 8, то ли на 16 (define в исходниках) по айдишнику, соответственно средний поиск по имени = кол-во интерфейсов/2, поиск по ид - кол-во интерфейсов/16 (или 32). Могу ошибаться, пишу по памяти.

 

А для чего нужно делать много ip link show eth0, что время выполнения критично?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 минут.

А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным.

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

На pppoe-БРАСах эти скрипты выполняются 10-20 секунд, а на IPOE с кучей вланов - 5 минут.

А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным.

Не перезагружайте шейпер в ЧНН :) У меня тоже так, грузится и дольше, бывает, и ниче....

 

Но мысль по поводу связи "времени имени интерфейса" с временем загрузки правил интересная, можно глянуть как ip/tc организовано (что передается в ядро - наверняка индекс интерфейса, который предварительно определяется из имени системным вызовом) и, особенно, есть ли там кеш.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На pppoe-БРАСах эти скрипты выполняются 10-20 секунд, а на IPOE с кучей вланов - 5 минут.

А т.к. перезагрузка шейперов происходит раз в час - время выполнения по мере роста нагрузки/числа вланов может стать критичным.

Какой смысл перезаливать все правила раз в час?

У нас написано небольшое приложение, которое держит в памяти все соответствия пользователь-шейп и при изменениях дергает соответствующие скрипты на исправление шейпов. Приличное время занимает только начальный старт (большую часть из которого занимает составление batch файла), последующие операции проходят практически моментально.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

legioner0

Так сложилось исторически :) Биллинг не использует каких-либо событий и управления NASами, а просто генерирует раз в час полный список шейперов и правил доступа, и скармливает всем серверам.

Не красиво, но просто и надежно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

legioner0

Так сложилось исторически :) Биллинг не использует каких-либо событий и управления NASами, а просто генерирует раз в час полный список шейперов и правил доступа, и скармливает всем серверам.

Не красиво, но просто и надежно.

У нас так же было, пока продавали интернет через vpn. Вместе с переходом на NASы пришлось программистам переделать биллинг на события

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перегрузил сервер добавив intel_idle.max_cstate=0, многое ранее тайное стало явным :) Я уже год не могу понять, почему при выставленном в биосе профиле "static max performance"(отключает все энергосберегайки и acpi) сервер у меня все равно уходил в c-state и игрался частотой.

Это возможно не всё!

http://stackoverflow.com/questions/12111954/context-switches-much-slower-in-new-linux-kernels

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не перестаю узнавать что-то новое из этой темы :)

Это возможно не всё!

http://stackoverflow...w-linux-kernels

Спасибо. Я оптимизировал iptables, изучал flame graph системный вызовов (уже тогда обратил внимание на intel_idle, но не придал этому значения), собранных с помощью perf, пересобирал десятки раз ядро, настраивал параметры napi, оптимизировал шейпер... а после этого сообщения запустил утилиту i7z и узнал, что у меня на бордерах и насах процессоры уходят в сон :). Даже в голову не приходило проверить частоту процессора, после настроек в биосе. Не думаю, что отключение энергосбережения сильно поможет, но все равно - слона то я и не заметил. Линукс негодяй, оказывается ему пофиг на настройки в биосе (тоже везде стоит "static max performance").

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.