Elisium Posted January 12, 2013 Posted January 12, 2013 (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 January 12, 2013 by Elisium Вставить ник Quote
Ivan_83 Posted January 12, 2013 Posted January 12, 2013 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 то сами себе злые буратины. Тогда включить, проверить диски, при необходимости пересобрать ядро с модулями. Вставить ник Quote
Elisium Posted January 12, 2013 Author Posted January 12, 2013 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 Гдето выгуглил, что высокие значения как раз и приводят к похожей ситуации ... По поводу остального: сервер достается "в наследство" уже через вторые руки и стоИт далековато =) Поэтому, прежде чем сделать всё феншуйно, хочется добиться стабильности на том, что есть. Вставить ник Quote
Ivan_83 Posted January 13, 2013 Posted January 13, 2013 там могло файлы покоцать, отсюда и появившееся нестабильное поведение. Вставить ник Quote
Elisium Posted January 14, 2013 Author Posted January 14, 2013 Сделал net.graph.maxalloc="65535" net.graph.maxdata="65535" net.graph.recvspace=35000 net.graph.maxdgram=35000 Вроде как полегчало - не ребутит ... Вставить ник Quote
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.