kaN5300 Posted January 31, 2012 Posted January 31, 2012 Накатил на парочку насов 9.0-RELEASE. Обновлялся через cvsup в обоих случаях с 7.4-STABLE до RELENG_9_0. После ребута пересборка и обновление всех портов (включая переход с mpd 5.5 на mpd-5.6) удаление устаревших либов и еще один ребут. Весь процесс обновления проходил удаленно. Первый тазик блестяще выстоял вечер воскресенья, после чего я принял решение по обновлению второго (о чем потом правда пожалел). Сетап обоих тазов такой: Ядро стандартное + ipfw_nat и нетграф Лоадер: net.graph.maxdata=65536 net.graph.maxalloc=65536 net.graph.maxdgram="128000" net.graph.recvspace="128000" kern.hz="1000" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 hw.igb.enable_aim=0 сисктл: dev.igb.0.rx_processing_limit=-1 dev.igb.1.rx_processing_limit=-1 dev.igb.0.enable_aim=0 dev.igb.1.enable_aim=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=10240 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.blackhole=2 net.inet.tcp.drop_synfin=1 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=100 kern.ipc.nmbclusters=400000 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=204800 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.link.ether.inet.proxyall=1 net.link.ifqmaxlen=10240 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.inet.tcp.tso=0 Обращаю внимание на то что net.isr принудительно через sysctl нигде не указан и на тазах с 7.4 картина такая: <kan5300@nas6>sysctl -a | grep isr net.isr.swi_count: 1616339 net.isr.drop: 0 net.isr.queued: 1763717 net.isr.deferred: 0 net.isr.directed: -1514625606 net.isr.count: -1583659636 net.isr.direct: 1 net.route.netisr_maxqlen: 4096 <kan5300@nas6>uptime 10:48AM up 42 days, 3:46, 1 user, load averages: 1.19, 1.28, 1.37 На 9.0 картина такая: net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.route.netisr_maxqlen: 256 Пиковые нагрузки на все тазы представляют в пиках до 800 pptp-туннелей, прокачка при этом около 40 kpps и пиковый lavg доходит до 5. Количество паник на 7.4 в среднем по 30 дней аптайма на сервак. Второй тазик с 9.0 пока себя показывает нормально, а вот первый произвольно уходит в ребут при kpps около 30 и выше при этом не оставляя никаких дампов для анализа. После ребута в /var/crash ничего нет за исключением старинного vmcore от прошлого года. За отсутствием дампа можно только гадать, изза чего это происходит. И я грежу на выставленный в ноль net.isr. На опеннете пишут что в 9.0 net.isr.direct только для чтения и предлагают использовать net.isr.direct_dispatch профили (direct, hybrid, deferred). Вот вырезка из комментариев к исходнику: SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr"); /*- * Three global direct dispatch policies are supported: * * NETISR_DISPATCH_QUEUED: All work is deferred for a netisr, regardless of * context (may be overriden by protocols). * * NETISR_DISPATCH_HYBRID: If the executing context allows direct dispatch, * and we're running on the CPU the work would be performed on, then direct * dispatch it if it wouldn't violate ordering constraints on the workstream. * * NETISR_DISPATCH_DIRECT: If the executing context allows direct dispatch, * always direct dispatch. (The default.) * * Notice that changing the global policy could lead to short periods of * misordered processing, but this is considered acceptable as compared to * the complexity of enforcing ordering during policy changes. Protocols can * override the global policy (when they're not doing that, they select * NETISR_DISPATCH_DEFAULT). */ Не совсем понятно, стоит ли включать в моем случае net.isr, т.к. драйвер igb в нашей ситуации прекрасно справляется с привязкой очередей к процессам. И в результате в top всегда утилизация всех CPU распределена равномерно (как на 7.4 так и на 9.0). Вопрос лишь в том, как добиться стабильной работы. dadv в своей статье "Тюнинг FreeBSD 8.2. Часть 1. Стабильность. (ЖЖ)" описывает проблему "dangling pointer", которая особенно проявляется при слишком частом или резком одновременном удалении системных интерфейсов под высокой нагрузкой. Но эта проблема вроде как должна быть уже решена на момент выхода 9.0 RELEASE за счет стараний Глеба Смирнова, который внес исправления в 9-CURRENT в 2011 году, насколько я понял из статьи. Врубать или не врубать ISR? И вторая мысль, опираясь на статью dadv. Пора переходить на amd64 архитектуру, ибо есть мнение что это не приведет к переполнению различных структур данных на прокаченных системах. По этому мы будем планировать постепенный ввод amd64 дистрибутивов и попробуем поиграться с режимами работы net.isr. Вставить ник Quote
Hawk128 Posted January 31, 2012 Posted January 31, 2012 Перевел НАСы на 9.0. Работают стабильно. Паник нет и не было вообще. Нагрузка до 1600 сессий в основном pptp + pppoe. Трафик через сервак по 500-600 kpps всего на вход и выход (около 150-200 на вход и столько же на выход каждой из сетевых). Так что пилите, и все будет хорошо. Вставить ник Quote
kaN5300 Posted January 31, 2012 Author Posted January 31, 2012 У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Что-то мне подсказывает, что у вас часть этих функций выполняет вышестоящая железяка. Так? Укажите пожалуйста используемую архитектуру и "sysctl -a | grep net.isr". Вставить ник Quote
Zohan Posted January 31, 2012 Posted January 31, 2012 kaN5300, однозначно переходить на amd64. Вставить ник Quote
kaN5300 Posted January 31, 2012 Author Posted January 31, 2012 Завтра будем инсталлить amd64/fbsd9.0 на ящик на базе i7 990X (про выбор сервера обсуждали здесь). Вставить ник Quote
roysbike Posted January 31, 2012 Posted January 31, 2012 Поставил 9.0 , после установки обновлял сорсы через svn . mdp5.6 + PF_NAT . HP proliant hw.model: Intel® Xeon® CPU E31240 @ 3.30GHz. Сетевухи igb0 igb1. Нагрузка смешная, не успел прокачать под нагрузкой/ На днях поставлю на второй, выложу результаты vpnxxx# uname -a FreeBSD vpn123.xxxxx 9.0-STABLE FreeBSD 9.0-STABLE #3 r230372: Fri Jan 20 07:46:43 UTC 2012 root@vpnxxxx:/usr/obj/usr/src/sys/GENERIC.current1 i386 vpnxxxx# netstat -w1 -h input (Total) output packets errs idrops bytes packets errs bytes colls 55k 0 0 35M 60k 0 47M 0 59k 0 0 39M 63k 0 52M 0 55k 0 0 33M 59k 0 46M 0 58k 0 0 36M 64k 0 50M 0 61k 0 0 38M 67k 0 52M 0 58k 0 0 38M 63k 0 51M 0 56k 0 0 35M 64k 0 52M 0 62k 0 0 40M 70k 0 58M 0 vpnxxxx# sysctl -a | grep isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.route.netisr_maxqlen: 4096 last pid: 78236; load averages: 0.63, 0.66, 0.62 up 5+16:10:55 22:48:13 114 processes: 6 running, 75 sleeping, 33 waiting CPU 0: 0.8% user, 0.0% nice, 7.8% system, 7.5% interrupt, 83.9% idle CPU 1: 0.4% user, 0.0% nice, 5.9% system, 8.6% interrupt, 85.1% idle CPU 2: 1.2% user, 0.0% nice, 4.3% system, 7.5% interrupt, 87.1% idle CPU 3: 0.8% user, 0.0% nice, 3.5% system, 3.9% interrupt, 91.8% idle Mem: 19M Active, 329M Inact, 325M Wired, 212K Cache, 112M Buf, 3115M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 32K CPU2 2 122.9H 95.26% idle{idle: cpu2} 11 root 155 ki31 0K 32K RUN 3 125.0H 92.19% idle{idle: cpu3} 11 root 155 ki31 0K 32K RUN 1 119.5H 89.70% idle{idle: cpu1} 11 root 155 ki31 0K 32K RUN 0 115.3H 81.59% idle{idle: cpu0} 12 root -92 - 0K 272K WAIT 2 325:31 6.05% intr{irq263: igb1:que} 13 root -16 - 0K 32K sleep 2 380:46 5.37% ng_queue{ng_queue2} 13 root -16 - 0K 32K sleep 3 381:31 4.88% ng_queue{ng_queue3} 13 root -16 - 0K 32K sleep 0 381:18 4.88% ng_queue{ng_queue0} 13 root -16 - 0K 32K sleep 3 380:51 4.69% ng_queue{ng_queue1} 12 root -92 - 0K 272K WAIT 0 318:42 4.39% intr{irq256: igb0:que} 12 root -92 - 0K 272K WAIT 0 332:59 4.30% intr{irq261: igb1:que} 12 root -92 - 0K 272K WAIT 1 330:21 4.30% intr{irq262: igb1:que} 12 root -92 - 0K 272K CPU3 3 323:35 4.20% intr{irq264: igb1:que} 12 root -92 - 0K 272K WAIT 1 105:45 1.56% intr{irq257: igb0:que} 12 root -92 - 0K 272K WAIT 2 102:19 1.37% intr{irq258: igb0:que} 12 root -92 - 0K 272K WAIT 3 107:03 1.27% intr{irq259: igb0:que} 1004 root 20 0 15064K 6728K select 0 63:39 0.20% snmpd 0 root -92 0 0K 168K - 1 40:17 0.10% kernel{igb0 que} 995 root 20 0 110M 46036K select 0 80:34 0.00% mpd5{mpd5} 12 root -60 - 0K 272K WAIT 0 17:49 0.00% intr{swi4: clock} 15 root -16 - 0K 8K - 1 11:35 0.00% yarrow 2 root -16 - 0K 8K pftm 0 8:09 0.00% pfpurge 0 root -92 0 0K 168K - 0 7:56 0.00% kernel{igb1 que} 8 root 16 - 0K 8K syncer 0 3:14 0.00% syncer 0 root -92 0 0K 168K - 1 2:05 0.00% kernel{igb1 que} 0 root -92 0 0K 168K - 2 2:00 0.00% kernel{igb1 que} 0 root -16 0 0K 168K sched 1 1:53 0.00% kernel{swapper} 0 root -92 0 0K 168K - 0 1:34 0.00% kernel{igb1 que} 877 root 20 0 9612K 1376K select 2 1:17 0.00% syslogd 1015 nagios 20 0 9568K 1348K select 2 0:11 0.00% nrpe2 12 root -60 - 0K 272K WAIT 1 0:10 0.00% intr{swi4: clock} Вставить ник Quote
kaN5300 Posted January 31, 2012 Author Posted January 31, 2012 roysbike, спасибо за выкладку результатов. Вижу, что isr вы также как и мы принудительно не выставляли. Сегодня наш второй таз на девятке поставил новый рекорд. 92 kpps / 700 tuns 1 minute lavg в пиковый момент протяженностью около 20 минут подпрыгнул до 6.8. Вечером колебался между 3.0 - 4.0. Самое главное - обошлось без ребутов, чего мы больше всего опасались. Вставить ник Quote
kaN5300 Posted February 2, 2012 Author Posted February 2, 2012 Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? Вставить ник Quote
Ilya Evseev Posted February 2, 2012 Posted February 2, 2012 Врубать или не врубать ISR? Пока прерывания сетевых карт равномерно нагружают все процессорные ядра - лучше не надо. Пора переходить на amd64 архитектуру На шлюзе разницы не видно. Ни по производительности, ни по надёжности. У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Аналогично, но nat через pf. Аптайм до 930 суток. Вставить ник Quote
adeep Posted February 2, 2012 Posted February 2, 2012 Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? работает. Вставить ник Quote
kaN5300 Posted February 2, 2012 Author Posted February 2, 2012 Кто-нибудь пытался запустить utm5_frw на 9.0 amd64? работает. У нас тоже пошло всё ровно. compat7x-amd64-7.3.703000.201008_1 поставили и всё завелось. Вставить ник Quote
Giga-Byte Posted February 5, 2012 Posted February 5, 2012 был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине), mpd выпал с воплями на No buffer space available на какойто операции с нодами. по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил. Увеличения памяти, MAXUSERS, пересборка ядра с нужными опциями - никчему не приводило, всё отваливалось через несколько часов снова. Анализ штатными утилитами используемой памяти криминала не выявил. Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку. 9.0-RELEASE amd64 Вставить ник Quote
kirush Posted February 6, 2012 Posted February 6, 2012 крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Вставить ник Quote
tunny Posted February 6, 2012 Posted February 6, 2012 был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине), mpd выпал с воплями на No buffer space available на какойто операции с нодами. по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил. Увеличения памяти, MAXUSERS, пересборка ядра с нужными опциями - никчему не приводило, всё отваливалось через несколько часов снова. Анализ штатными утилитами используемой памяти криминала не выявил. Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку. 9.0-RELEASE amd64 дайте памяти нетграфу Вставить ник Quote
Ivan_83 Posted February 6, 2012 Posted February 6, 2012 No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил - не хватка сетевых буферов (мбуф), vmstat -z, смотреть столбик Fail, не смотреть "ХХ Bucket". и netstat -m kern.ipc.nmbclusters=262144 # Maximum number of mbuf clusters allowed // netstat -m kern.ipc.nmbjumbop=262144 # Maximum number of mbuf page size jumbo clusters allowed. pagesize(4k/8k) kern.ipc.nmbjumbo9=262144 # Maximum number of mbuf 9k jumbo clusters allowed kern.ipc.nmbjumbo16=262144 # Maximum number of mbuf 16k jumbo clusters allowed Не стоит боятся их задирать, по факту это задаёт максимально возможное количество элементов, а не фактически их выделяет. Вставить ник Quote
Giga-Byte Posted February 7, 2012 Posted February 7, 2012 :) написал же, не выявил криминала. возможно это даже не фряшная проблема, поставил вторую машину, попробую выявить. Вставить ник Quote
AlKov Posted February 8, 2012 Posted February 8, 2012 крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 А откуда такие "страшные" цифры? Для интереса попробовал "на летУ" установить net.graph.maxdgram=8388608 и net.graph.recvspace=8388608. mpd тут же ушёл в ступор (ошибка 678 у виндовых клиентов).. Пришлось вернуть всё взад и ребутать mpd. Правда перед этим не увеличивал kern.ipc.maxsockbuf (262144) и дело было на 8.0 P.S. Нагуглил довольно интересную подборку статей (kirush, не ваша случаем ? ;-)), изучаю.. Вставить ник Quote
Giga-Byte Posted February 9, 2012 Posted February 9, 2012 AlKov, вот после таких утверждений меня работа и находит :)))) жаль смайликов подходящих нету, выразить Ымоции пы.сы. надо прекращать флейм, обсуждаем ТЕМУ Вставить ник Quote
kaN5300 Posted February 9, 2012 Author Posted February 9, 2012 крутите netgraph: net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 А откуда такие "страшные" цифры? Для интереса попробовал "на летУ" установить net.graph.maxdgram=8388608 и net.graph.recvspace=8388608. mpd тут же ушёл в ступор (ошибка 678 у виндовых клиентов).. Пришлось вернуть всё взад и ребутать mpd. Правда перед этим не увеличивал kern.ipc.maxsockbuf (262144) и дело было на 8.0 P.S. Нагуглил довольно интересную подборку статей (kirush, не ваша случаем ? ;-)), изучаю.. У Дадва офигенные статьи. Отправил их в мемориз и засветился в коментах. Спрашивал, будут ли заметки о 9.0. Сказал что в продакш дот-зироу релизы не выставляет. Так что ждем 9.1 и тыкаем dadv'a. Вставить ник Quote
kaN5300 Posted February 9, 2012 Author Posted February 9, 2012 (edited) Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы. Edited February 9, 2012 by kaN5300 Вставить ник Quote
roysbike Posted February 10, 2012 Posted February 10, 2012 Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы. зачем вы используете amd64? На каком чипе используете сетевые карты? Вставить ник Quote
AlKov Posted February 11, 2012 Posted February 11, 2012 И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? Вставить ник Quote
Giga-Byte Posted February 12, 2012 Posted February 12, 2012 И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? из /dev/random ^))) kirush, объясни же человеку Вставить ник Quote
dadv Posted March 5, 2012 Posted March 5, 2012 И всё же - можно где-то узнать "происхождение" этих параметров? net.graph.maxdgram=8388608 net.graph.recvspace=8388608 kern.ipc.maxsockbuf=83886080 Почему именно 8 388 608 (8 Мб??) и 83 886 080 (80 Мб??) И есть ли какое-то соотношение между значением net.graph.maxdgram и kern.ipc.maxsockbuf? Связаны ли эти параметры с размером памяти? Это параметры из моей статьи. Они прекрасно работают у меня на 4G памяти и amd64 (использовать i386 для таких задач - нарываться на неприятности, даже если памяти меньше 4G). kern.ipc.maxsockbuf влияет, в частности, на работу команды ngctl list, которой очень удобно снимать количество подключенных сессий (она отрабатывает на порядок быстрее чем ifconfig). Но ngctl list при большом количестве сессий вместо результата выдавало у меня ошибку даже после нескольких удвоений дефолта, вплоть до 8M. Тогда, обозлившись, я удесятерил - и ngctl list заработал. Это было при более чем 1500 сессях. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.