![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mpd-5.5
Первый стресс-тест mpd-5.5/PPPoE под FreeBSD 8.2-STABLE/amd64 на реальной нагрузке.
Система настроена решать одну задачу - терминировать пользовательские сессии PPPoE с AAA через RADIUS, с шейпингом трафика и анонсированием абонентских IP-адресов в ядро сети через OSPF. На машине нет NAT (адреса реальные), нет netflow (собирается на другом роутере), нет BGP.
В час наибольшей нагрузки отмечено:
- 1812 сессий PPPoE;
- средняя нагрузка по ядрам процессора 2% user time / 88% (system time + interrupts) (CPU0: 2+90, CPU1: 2+89, CPU2: 2+90, CPU3: 3+86);
- 1184.9Mbit/s трафика в сторону клиентов и 830.9Mbit/s от них (итого 2015.8Mbit/s);
- 549.8Kpps: на интерфейсе lagg0 136.2Kpps in, 120.3Kpps out и на lagg1 139.0Kpps in, 154.3Kpps out;
- до 102K прерываний в секунду (device polling не использовался);
- использовано памяти:
Mem: 101M Active, 41M Inact, 486M Wired, 1644K Cache, 138M Buf, 3314M Free - в среднем на одну PPPoE-сессию приходилось 654.1Kbit/s трафика на вход и 434.2Kbit/s на выход.
То есть, на каждый процент загрузки CPU пришлось по 20 сессий.
Система продолжала быть отзывчивой на ssh так же, как и без нагрузки.
Железо:
- SuperMicro SuperServer 5016T-MTFB с двумя гигабитными интегрированными сетевыми Intel 82574L (драйвер em) и платой IPMI 2.0 с выделенным портом 100M;
- дополнительная двухпортовая сетевая карта Intel 82576 (драйвер igb);
- процессор Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (четыре ядра, гипертрединг отключен в BIOS Setup, 4M Cache, 4.80 GT/s Intel® QPI);
- 4GB памяти ECC;
- в качестве загрузочного носителя SSD 64GB (KINGSTON SNV425S264GB), при загрузке монтируется только для чтения (система собрана в виде NanoBSD, без свопа).
Общая стоимость железа около 60 тысяч рублей (всё железо новое).
Сетевые em0 и em1 объединены в lagg0, на нём есть IP-адрес и нет vlan-ов, это аплинк. Сетевые igb0 и igb1 объединены в lagg1, на котором нет IP, зато создано 596 vlan-ов, каждый из которых несет PPPoE-трафик пользователей. Шейпинг выполнен через ipfw/dummynet - на каждого подключенного пользователя dummynet динамически (pipe ... mask) создает по две индивидуальных трубы, на вход и на выход, в соответствии с тарифом пользователя. Весь шейпинг делается двумя правилами ipfw, список правил не растет при росте количества абонентов:pipe tablearg ip from any to table(11) in
pipe tablearg ip from table(12) to any in
Для сравнения: бывшая в употреблении Cisco 7201 на usedcisco.ru стоит $11400 $10900 (примерно в 5.5 раз дороже), срок поставки 3 недели. На этой же задаче и на этих же пользователях обрабатывает около 10 сессий на процент загрузки CPU (то есть, вдвое меньше), причем при высоких загрузках вносит большие задержки и сама с трудом управляется по telnet. Поэтому приходится ограничивать количество сессий на ней (не более 700), чтобы держать нагрузку в пределах 75%. Стоит отметить, что при маленьких нагрузках (ближе к нулю) количество сессий на процент загрузки CPU у обоих систем растет в разы.
Зато Cisco - продукт, и умеет гораздо больше, например, ISG. А FreeBSD - конструктор, и требует существенного тюнинга. Про тюнинг как-нибудь в другой раз.
Update: для проверки провёл второй тест на FreeBSD с целью удержать загрузку в пределах 75%. При прочих равных условиях для этого оказалось нужным ограничить количество сессий PPPoE в 1500. Подтверждается прямая пропорциональность: 1800/0.9=1500/0.75=2000, что даёт нам прогноз стопроцентной загрузки при 2000 сессиях.
На деле у меня пока достаточно железок, чтобы держать нагрузку в пике на уровне 35% :-)
no subject
Не, мне ничего выкладывать не надо) Я и сам могу.
> по-ядерную загрузку серверов с разбивкой на user/nice/system/interrupt
idle еще забыли
Я так понимаю через внешний скрипт? т.к. mib'а ucd изначально делалась для линуха, и параметры загрузки cpu там чисто линуксовые, т.е. вместо user/nice/system/interrupt/idle там идут немного другие.
Еще хотел у вас спросить, мониторите ли вы загрузку памяти вообще для сервера?
С ней та же самая ботва в ucd. Там все для линуха, а у фри вообще некоторых типов памяти нет.
no subject
Нет, не забыл - idle не нужен :-) После построения графика user+nice (вместо in) и system+interrupt (вместо out) уже рисовать idle избыточно, и так всё видно.
> Я так понимаю через внешний скрипт?
Да.
> Еще хотел у вас спросить, мониторите ли вы загрузку памяти вообще для сервера?
Нет, так-как у меня её переизбыток.
no subject
не понял, что вы имеете ввиду под "вместо in/out"?
утилизация проца снимается чрезе значения ssCpuRaw*?
no subject
mrtg рисует на одном графике два значения, одно "in", одно "out", туда я ему подсовываю две суммы, user+nice(вместо in) и system+interrupt (вместо out).
> утилизация проца снимается чрезе значения ssCpuRaw*?
По сути да, но цифры берутся из sysctl kern.cp_times, там они отдельно для каждого ядра.
no subject
ну вообще как настроете его, так и будет рисовать. в rrd ведь можно сделать график в виде стэка, чтоб получилось примерно вот такое __http://img-fotki.yandex.ru/get/5809/16519813.0/0_7328e_ba1a00af_XXXL.jpg , что выглядит более логично.
но у вас cpu times, а не проценты, тут я теряюсь как в них можно разобраться и как вычислить.
no subject
По snmp возвращаем ему raw tick counters, mrtg вычисляет дельту с предыдущим измерением, делит на интервал измерения, получает приращение в тиках на ядро за секунду (в среднем за интервал измерения), для этого числа есть максимум - частота statclock, константа при фиксированном HZ. Суммируя приращения по категориям (usr+nice и system+intr) и умножая результат на 100 и деля на эту константу (те самые арифметические операции для Target), mrtg получает процент и рисует его.
И так для каждого ядра отдельно.
no subject
Но к чему я это все. Интересно было узнать, как народ вообще пользуется snmp на фре для мониторинга. На мой взгляд ucd для фри как-то не особо подходит.
Спасибо!
no subject
http://piccy.info/view3/2404329/dd9f28f8ac74d3d2f698ff14c305fe31/
вот скрипт для снятия:
#!/usr/bin/perl
use warnings;
use strict;
my $host= $ARGV[0];
my $snmpauth= $ARGV[1];
#.1.3.6.1.4.1.2021.11.
my $user= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawUser.0`; chop $user;
my $nice= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawNice.0`; chop $nice;
my $system= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawSystem.0`; chop $system;
my $idle= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawIdle.0`; chop $idle;
my $wait= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawWait.0`; chop $wait;
my $kernel= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawKernel.0`; chop $kernel;
my $interrupt= `/usr/local/bin/snmpget $snmpauth -O qv $host UCD-SNMP-MIB::ssCpuRawInterrupt.0`; chop $interrupt;
print "user:$user nice:$nice system:$system idle:$idle wait:$wait kernel:$kernel interrupt:$interrupt";
мож кто спасибо скажет )
no subject
no subject
no subject
no subject
А вы не подскажете: http://piccy.info/view3/2368834/512139edc56eea736881affcda490eca/
проблема в том, что шина не может прерывания уже генерировать, или может где-то ещё?
ЗЫ. График по всем процессорам на подходе )
no subject
Надо смотреть top -SHPI
no subject
no subject