Jump to content
Калькуляторы

NAS на FreeBSD 9.0. Тестирование под нагрузкой.

Накатил на парочку насов 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.

Share this post


Link to post
Share on other sites

Перевел НАСы на 9.0. Работают стабильно. Паник нет и не было вообще. Нагрузка до 1600 сессий в основном pptp + pppoe. Трафик через сервак по 500-600 kpps всего на вход и выход (около 150-200 на вход и столько же на выход каждой из сетевых).

Так что пилите, и все будет хорошо.

Share this post


Link to post
Share on other sites

У нас боксы с решением all-in-one с nat/shaper/firewall/netflow. Что-то мне подсказывает, что у вас часть этих функций выполняет вышестоящая железяка. Так? Укажите пожалуйста используемую архитектуру и "sysctl -a | grep net.isr".

Share this post


Link to post
Share on other sites

kaN5300, однозначно переходить на amd64.

Share this post


Link to post
Share on other sites

Поставил 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}

Share this post


Link to post
Share on other sites

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

 

Сегодня наш второй таз на девятке поставил новый рекорд.

 

92 kpps / 700 tuns

 

1 minute lavg в пиковый момент протяженностью около 20 минут подпрыгнул до 6.8. Вечером колебался между 3.0 - 4.0. Самое главное - обошлось без ребутов, чего мы больше всего опасались.

Share this post


Link to post
Share on other sites

Кто-нибудь пытался запустить utm5_frw на 9.0 amd64?

Share this post


Link to post
Share on other sites

Врубать или не врубать ISR?

Пока прерывания сетевых карт равномерно нагружают все процессорные ядра - лучше не надо.

 

Пора переходить на amd64 архитектуру

На шлюзе разницы не видно. Ни по производительности, ни по надёжности.

 

У нас боксы с решением all-in-one с nat/shaper/firewall/netflow.

Аналогично, но nat через pf. Аптайм до 930 суток.

Share this post


Link to post
Share on other sites

Кто-нибудь пытался запустить utm5_frw на 9.0 amd64?

работает.

Share this post


Link to post
Share on other sites

Кто-нибудь пытался запустить utm5_frw на 9.0 amd64?

работает.

 

У нас тоже пошло всё ровно. compat7x-amd64-7.3.703000.201008_1 поставили и всё завелось.

Share this post


Link to post
Share on other sites

был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине),

mpd выпал с воплями на No buffer space available на какойто операции с нодами.

по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил.

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

Анализ штатными утилитами используемой памяти криминала не выявил.

Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку.

9.0-RELEASE amd64

Share this post


Link to post
Share on other sites

крутите netgraph:

net.graph.maxdgram=8388608

net.graph.recvspace=8388608

kern.ipc.maxsockbuf=83886080

Share this post


Link to post
Share on other sites

был неприятный момент когда все коннекты отвалились (PPPoE и PPTP на одной машине),

mpd выпал с воплями на No buffer space available на какойто операции с нодами.

по SSH к серверу достучался, но весь софт хором кричал No Buffer Space Available, в т.ч. и mpd, даже ICMP не ходил.

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

Анализ штатными утилитами используемой памяти криминала не выявил.

Уменьшил kern.maxsockbuf до 256к, пока работает, может уже недельку.

9.0-RELEASE amd64

дайте памяти нетграфу

Share this post


Link to post
Share on other sites

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

Не стоит боятся их задирать, по факту это задаёт максимально возможное количество элементов, а не фактически их выделяет.

Share this post


Link to post
Share on other sites

:)

написал же, не выявил криминала.

возможно это даже не фряшная проблема, поставил вторую машину, попробую выявить.

Share this post


Link to post
Share on other sites

крутите 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, не ваша случаем ? ;-)), изучаю..

Share this post


Link to post
Share on other sites

AlKov, вот после таких утверждений меня работа и находит :))))

жаль смайликов подходящих нету, выразить Ымоции

 

пы.сы. надо прекращать флейм, обсуждаем ТЕМУ

Share this post


Link to post
Share on other sites

крутите 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.

Share this post


Link to post
Share on other sites

Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы.

Edited by kaN5300

Share this post


Link to post
Share on other sites

Тот инсталл который помирал был отброшен на 7.4-RELEASE и вобще там не все в порядке с железом, это отдельный вопрос. Тот второй сервер о котором я писал всё-таки допустил один произвольный ребут. Самое интересное происходит на нашем новом NAS на базе процессора i7-990X. Туда был накачен 9.0-RELEASE amd64 с последующим обновлением до 9.0-STABLE. Сервак проработал пока чуть больше суток. В пике 35 kpps, 700 туннелей и idle самого загруженного ядра составлял при этом 70%. Видно что запас по производительности есть. Теперь главное - добиться стабильной работы.

зачем вы используете amd64? На каком чипе используете сетевые карты?

Share this post


Link to post
Share on other sites

И всё же - можно где-то узнать "происхождение" этих параметров?

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? Связаны ли эти параметры с размером памяти?

Share this post


Link to post
Share on other sites

И всё же - можно где-то узнать "происхождение" этих параметров?

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, объясни же человеку

Share this post


Link to post
Share on other sites

И всё же - можно где-то узнать "происхождение" этих параметров?

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 сессях.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this