Jump to content

Recommended Posts

Posted (edited)

Всем доброго времени.

 

Есть некий брендовый сервер:

проц 2 х Intel(R) Xeon(R) CPU X5680  @ 3.33GHz
сетевка Intel 10GBase-SR SFP+
8ГБ памяти.

 

FreeBSD intel.**** 8.2-RELEASE FreeBSD 8.2-RELEASE #2: Mon Mar 28 12:01:32 EEST 2011     root@intel.****:/usr/src/sys/amd64/compile/INTEL  amd64

 

Из функций:

БГП на Квагге, шейпер на ипфв (НАТа нет, всего правил ~50, из них 20 клиентские пайпы), нетфлов (ng_netflow)

 

Симптомы:

После внеплановой перезагрузки сервер прекратил отдавать статистику по нетфлов. Нетграф конфигурится из файлика netflow.txt (ниже).

Для проверки делаю ngctl list. Сервер подвисает секунды на три, после чего моментальный ребут (как будто нажали ресет). Тоже самое, если пытаться переконфигурить ноду.

Если не делать этого, то все работает преотлично, но трафик тогда, само собой, не считает. А надо.

 

Есть предположения, что это/изза чего может быть ?

 

 

 

 

Файлы:

 

netflow.txt

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/ххх.ххх.ххх.ххх:8888

 

 

vmstat -z

Ошибок нет

 

 

loader.conf

geom_mirror_load=YES

net.graph.maxdata=4096
kern.ipc.nmbclusters=262144
net.isr.defaultqlimit=4096
net.link.ifqmaxlen=1024
net.inet.tcp.tcbhashsize=16384
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.syncache.bucketlimit=512

dummynet_load="YES"
coretemp_load="YES"

Остальные ng_* модули вкомпилены в ядро.

 

sysctl.conf

net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.hash_size=65535
kern.ipc.nmbclusters=262144
kern.ipc.nmbjumbop=262144
net.inet.ip.redirect=0
dev.ix.0.rx_processing_limit=256
dev.ix.1.rx_processing_limit=256

net.inet.udp.blackhole=1
net.inet.tcp.blackhole=2

net.inet.ip.fastforwarding=1
net.inet.ip.dummynet.pipe_slot_limit=1000
net.graph.recvspace=350000
net.graph.maxdgram=350000
kern.ipc.maxsockbuf=83886080
kern.ipc.somaxconn=4096

 

 

 

netstat -w1

            input        (Total)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
  1131772     0     0  953301770    1119470     0  950006778     0
  1074553     0     0  903729963    1071391     0  902367594     0
  1117268     0     0  952915640    1113422     0  946952733     0

 

top -SHPI

last pid: 40055;  load averages:  0.52,  0.60,  0.53     up 0+05:20:44  17:32:44
201 processes: 15 running, 136 sleeping, 50 waiting
CPU 0:   0.0% user,  0.0% nice,  2.6% system, 46.2% interrupt, 51.1% idle
CPU 1:   0.0% user,  0.0% nice,  0.4% system, 47.0% interrupt, 52.6% idle
CPU 2:   0.0% user,  0.0% nice,  0.4% system, 47.6% interrupt, 52.1% idle
CPU 3:   0.0% user,  0.0% nice,  0.0% system, 57.7% interrupt, 42.3% idle
CPU 4:   0.0% user,  0.0% nice,  0.0% system, 51.7% interrupt, 48.3% idle
CPU 5:   0.0% user,  0.0% nice,  0.0% system, 50.2% interrupt, 49.8% idle
CPU 6:   0.4% user,  0.0% nice,  2.2% system, 59.2% interrupt, 38.2% idle
CPU 7:   0.0% user,  0.0% nice,  1.1% system, 62.4% interrupt, 36.5% idle
CPU 8:   0.7% user,  0.0% nice, 12.7% system,  0.0% interrupt, 86.5% idle
CPU 9:   1.5% user,  0.0% nice, 10.5% system,  0.0% interrupt, 88.0% idle
CPU 10:  0.0% user,  0.0% nice,  8.2% system,  0.0% interrupt, 91.8% idle
CPU 11:  0.0% user,  0.0% nice,  8.2% system,  0.0% interrupt, 91.8% idle
Mem: 56M Active, 13M Inact, 233M Wired, 168K Cache, 17M Buf, 11G Free
Swap: 32G Total, 32G Free

 PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  11 root      171 ki31     0K   192K CPU10  10 299:04 95.56% {idle: cpu10}
  11 root      171 ki31     0K   192K CPU11  11 304:32 92.68% {idle: cpu11}
  11 root      171 ki31     0K   192K CPU9    9 284:16 87.79% {idle: cpu9}
  11 root      171 ki31     0K   192K CPU8    8 268:14 85.99% {idle: cpu8}
  12 root      -68    -     0K   832K CPU7    7 162:31 64.26% {irq282: ix1:que
  12 root      -68    -     0K   832K WAIT    1 133:01 56.69% {irq276: ix1:que
  12 root      -68    -     0K   832K WAIT    6 161:30 55.66% {irq281: ix1:que
  11 root      171 ki31     0K   192K CPU0    0 129:22 54.69% {idle: cpu0}
  12 root      -68    -     0K   832K CPU2    2 135:52 54.30% {irq277: ix1:que
  12 root      -68    -     0K   832K WAIT    3 136:07 53.86% {irq278: ix1:que
  12 root      -68    -     0K   832K WAIT    0 136:07 53.17% {irq275: ix1:que
  12 root      -68    -     0K   832K WAIT    4 135:12 53.17% {irq279: ix1:que
  11 root      171 ki31     0K   192K RUN     5 180:22 52.98% {idle: cpu5}
  11 root      171 ki31     0K   192K CPU4    4 185:05 49.46% {idle: cpu4}
  12 root      -68    -     0K   832K WAIT    5 140:05 49.17% {irq280: ix1:que
  11 root      171 ki31     0K   192K CPU3    3 184:04 48.10% {idle: cpu3}
  11 root      171 ki31     0K   192K RUN     1 186:11 47.56% {idle: cpu1}
  11 root      171 ki31     0K   192K RUN     2 183:48 47.46% {idle: cpu2}
  11 root      171 ki31     0K   192K RUN     6 145:41 42.97% {idle: cpu6}
  11 root      171 ki31     0K   192K RUN     7 147:24 34.96% {idle: cpu7}
   0 root      -68    0     0K   528K -       9  17:46  8.25% {ix1 que}
   0 root      -68    0     0K   528K -       8  19:22  8.06% {ix1 que}
   0 root      -68    0     0K   528K -      10  17:45  6.88% {ix1 que}

Edited by Elisium
Posted
net.graph.maxdata=4096

net.graph.maxalloc="65535" # Maximum number of non-data queue items to allocate / limit the damage of a leak

net.graph.maxdata="65535" # Maximum number of data queue items to allocate / limit the damage of a DoS

 

Остальные ng_* модули вкомпилены в ядро.

Смысла нет.

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

Нетграф модули грузятся автоматом, как и ипфв и много чего ещё.

 

Если у вас не включена бэкграундовая fsck то сами себе злые буратины. Тогда включить, проверить диски, при необходимости пересобрать ядро с модулями.

Posted
net.graph.maxdata=4096

net.graph.maxalloc="65535" # Maximum number of non-data queue items to allocate / limit the damage of a leak

net.graph.maxdata="65535" # Maximum number of data queue items to allocate / limit the damage of a DoS

Хм. Попробую, спасибо. Хотя на другом сервере 4к хватало.

 

Имеет ли смысл УМЕНЬШИТЬ

net.graph.recvspace=350000
net.graph.maxdgram=350000

Гдето выгуглил, что высокие значения как раз и приводят к похожей ситуации ...

 

По поводу остального: сервер достается "в наследство" уже через вторые руки и стоИт далековато =)

Поэтому, прежде чем сделать всё феншуйно, хочется добиться стабильности на том, что есть.

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.