Elisium

Только что для теста забил в него 25 вланов (1-24, 28й порты). Все на месте, не упал. Хотя уже немного повидав эти свичи, мой успешный эксперимент ни о чем не говорит =)

После пары дней тестов... Ну, что тут сказать. Выставил по 6 очередей на каждую сетевуху. Загрузил все 12 ядер. По сравнению с данными из самого первого поста изменилось только ЛА: с 10 до 8,2 Что, в принципе, ожидаемо - к 8ми ядрам заработали еще +4 ядра. По ппс\трафику изменений +- почти нет: 1200Кпс\4,7ГБт суммарного трафа. Ну и дамминет 5-6% показывает.

о_О Посмотрел в sysctl hw - тут такого нет. Разные em\igb\bxe есть. А ixgbe - нет. Апдейт: а тут есть ... как так. [root@router /usr/src/sys/dev/ixgbe]# grep TUNABLE_INT ./* ./ixgbe.c:TUNABLE_INT("hw.ixgbe.enable_aim", &ixgbe_enable_aim); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.max_interrupt_rate", &ixgbe_max_interrupt_rate); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.rx_process_limit", &ixgbe_rx_process_limit); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.tx_process_limit", &ixgbe_tx_process_limit); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.enable_msix", &ixgbe_enable_msix); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.num_queues", &ixgbe_num_queues); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.txd", &ixgbe_txd); ./ixgbe.c:TUNABLE_INT("hw.ixgbe.rxd", &ixgbe_rxd); Апдейт2: Погуглил. Пишут, что параметры таки есть, но через сисцтл недоступны. Вот тут в рассылке про это Апдейт3: Все выставил. Ночью ребутну - проверю.

Карта 10G Intel какая-то. pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000

Затем, что было очень много ошибок в NetFlow IPv4 cache. Увеличили кеш - ошибки пропали. п.с. Из-за кучи ошибок были какие-то проблемы в работе. Уже не упомню, что именно.

Коротенько как-то. А NBUCKETS поправить не надо было? :) Может и надо было =) Раз начали, так уже и пишите, на что там поправить надо ) Я же в этих ваших исходниках не разбираюсь. п.с. Теоретически, NBUCKETS=CACHESIZE/4, не ?

Вот еще вдогонку патчик для нетфлов для настройки размера кэша на лету. Появляется еще одна переменная в сисцтл netflow_cachesize. netflow.c.diff.txt

sysctl dev.ix.0 NetFlow настроен так: mkpeer ipfw: netflow 100 iface0 name ipfw:100 netflow msg netflow: setdlt { iface = 0 dlt = 12 } msg netflow: settimeouts { inactive=20 active=20 } mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export connect inet/х.х.х.х:уууу и tee в фаерволе. По нагрузке: на сейчас ЛА=6.3, выключаю - ЛА=4.8, включаю обратно - минуты через 3 опять 6.2

Пока пытаемся обновиться. Но на удаленной техплощадке, где этот сервер стоит, сначала нужно заменить неисправный КВМ =) Мало ли что .... Обновлюсь - отпишусь. Мысль интересная. Но как-то я сходу не нагуглил такой вариант. Сисцтл для этого нет, а ковырять исходники я не силен. п.с. Как я понимаю, карточка аппаратно поддерживает 8 очередей. Не факт, что ими вообще можно софтово управлять.

Это тест на внимательность =) п.с. скрипт в фоне, рулит правилами в фаерволе.

Собственно, вот: При включенном deferred и fastforwarding=0 top -SHPI sysctl net.isr .. и при direct и ff=1 top -SHPI sysctl net.isr pps примерно 800К. Час пик уже прошел =( Прерывания от сетевух привязаны так: Шесть первых прерываний первой сетевухи на ядра 0-5, 7е и 8е - на ядра 4,5 Шесть первых прерываний второй сетевухи на ядра 6-11, 7е и 8е - на ядра 10,11. Разницу в нагрузке на сервер не особо заметно. Более того, не понимаю, почему в первом случае указано net.isr.numthreads: 12, но реально в топе видно только 8 работающих. Соответственно, загружены только первые 8 ядер. В чем подвох ?

Ну, формально, ничего =) Просто сетевух две - у каждой по 8 очередей. А процов 12. Как бы, красиво не прибить. п.с. Пробовал. Видимого эффекта не обнаружено.

Дамминет прибит к 0му ядру. Однако, в час пик его загрузка поднимается до 5%. Ок, сегодня ночью попробую опять опции нет.иср с выключеным фастфорвардингом.

Нет. Принимаем\отдаем дефолты. Иксы рулятся ранее на циске.

net.inet.ip.fastforwarding=1 net.inet.ip.dummynet.io_fast=1 HT выключен - установлено два проца. Вернул все как было, ибо нагрузка заметно выросла. Увеличил обьем кеша для нетфлоу - поставил 1М. Ошибок в его сторону не наблюдается. Поправили шейпер. Было #unlim 50 day ${fwcmd} pipe 500 config mask dst-ip 0xffffffff bw 50Mbit/s queue 10 gred 0.002/15/30/0.1 ${fwcmd} pipe 501 config mask src-ip 0xffffffff bw 50Mbit/s queue 10 gred 0.002/15/30/0.1 Стало #unlim 50 day ${fwcmd} pipe 500 config mask dst-ip 0xffffffff bw 50Mbit/s queue 100 ${fwcmd} pipe 501 config mask src-ip 0xffffffff bw 50Mbit/s queue 100 Тарифная скорость вернулась +- в норму Но так и остался открытым вопрос, что еще можно сделать для снижения нагрузки. Ликвидировать пользователей не предлагать =)