ichthyandr Опубликовано 6 апреля, 2012 · Жалоба А как при этом трафик ходит, опишите? (роутинг, или нетграф, есть ли шейпинг, etc, чего с фиреволлом, в общем хочется услышать путь прохождения пакета). Есть идея, которая легко реализуется и скорее всего поможет. mpd используем для раздачи туннелями, шейпим им же, как он через нетграф это делает, я не исследовал, файрволл - ${FwCMD} -f flush ${FwCMD} add allow ip from any to any via lo0 ${FwCMD} add deny ip from any to 127.0.0.0/8 ${FwCMD} add deny ip from 127.0.0.0/8 to any ${FwCMD} add deny icmp from any to any frag ${FwCMD} add deny log icmp from any to 255.255.255.255 in via ${LanOut} ${FwCMD} add deny log icmp from any to 255.255.255.255 out via ${LanOut} ${FwCMD} add allow ip from Блок А/27 to 224.0.0.0/4 in ${FwCMD} add allow ip from 224.0.0.0/4 to Блок А/27 out ${FwCMD} add deny ip from any to 0.0.0.0/8 in via ${LanOut} ${FwCMD} add deny ip from any to 192.168.0.0/16 in via ${LanOut} ${FwCMD} add deny ip from any to 240.0.0.0/4 in via ${LanOut} ${FwCMD} add deny ip from any to 169.254.0.0/16 in via ${LanOut} ${FwCMD} add deny icmp from any to any frag ${FwCMD} add deny log icmp from any to 255.255.255.255 in via ${LanOut} ${FwCMD} add deny log icmp from any to 255.255.255.255 out via ${LanOut} ${FwCMD} add deny ip from 0.0.0.0/8 to any out via ${LanOut} ${FwCMD} add deny ip from 192.168.0.0/16 to any out via ${LanOut} ${FwCMD} add deny ip from 240.0.0.0/4 to any out via ${LanOut} ${FwCMD} add deny ip from 169.254.0.0/16 to any out via ${LanOut} ${FwCMD} add deny ip from 224.0.0.0/4 to any out via ${LanOut} ${FwCMD} add allow tcp from any to any established ${FwCMD} add allow ip from ${IpOut} to any out xmit ${LanOut} # NetBios ${FwCMD} add reset all from any 135 to any ${FwCMD} add reset all from any to any 135 ${FwCMD} add reset all from any 137-139 to any ${FwCMD} add reset all from any to any 137-139 ${FwCMD} add reset all from any 445 to any ${FwCMD} add reset all from any to any 445 ${FwCMD} add reset all from any 1026-1027 to any ${FwCMD} add reset all from any to any 1026-1027 ${FwCMD} add reset all from any 1029 to any ${FwCMD} add reset all from any to any 1029 ${FwCMD} add reset all from any 1433-1434 to any ${FwCMD} add reset all from any to any 1433-1434 ${FwCMD} add reset all from any 2048 to any ${FwCMD} add reset all from any to any 2048 ${FwCMD} add allow ip from Блок А/20 to any ${FwCMD} add allow ip from any to Блок А/20 ${FwCMD} add allow ip from Блок Б/21 to any ${FwCMD} add allow ip from any to Блок Б/21 ${FwCMD} add allow ip from Блок В/22 to any ${FwCMD} add allow ip from any to Блок В/22 ${FwCMD} add allow ip from Блок Г/20 to any ${FwCMD} add allow ip from any to Блок Г/22 ${FwCMD} add allow ip from Адрес-1 to any ${FwCMD} add allow ip from any to Адрес-1 ${FwCMD} add allow udp from any 520 to any ${FwCMD} add allow udp from any to any 520 ${FwCMD} add allow udp from any 53 to any #${FwCMD} add allow udp from any to any 53 ${FwCMD} add allow udp from any to any 123 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9991 to Адрес-2 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9992 to Адрес-2 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9993 to Адрес-2 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9991 to Адрес-3 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9992 to Адрес-3 via ${LanOut} ${FwCMD} add allow udp from ${IpOut} 9993 to Адрес-3 via ${LanOut} ${FwCMD} add allow tcp from 172.16.0.14 to ${IpIn} 5006 via ${LanIn} ${FwCMD} add allow tcp from 172.16.0.4 to ${IpIn} 5006 via ${LanIn} ${FwCMD} add allow tcp from 192.168.0.0/24 to ${IpIn} 5006 via ${LanIn} ${FwCMD} add deny tcp from any to ${IpIn} 5006 via ${LanIn} ${FwCMD} add allow tcp from 192.168.0.0/24 to ${IpIn} 22 via ${LanIn} ${FwCMD} add reset tcp from any to me dst-port 20 ${FwCMD} add reset tcp from any to me dst-port 21 ${FwCMD} add deny tcp from any to me dst-port 22 ${FwCMD} add reset tcp from any to me dst-port 23 ${FwCMD} add allow icmp from any to any icmptypes 0,8,11 ${FwCMD} add allow gre from any to any via ${LanIn} ${FwCMD} add allow tcp from any to any via ${LanIn} ${FwCMD} add allow udp from any to any via ${LanIn} ${FwCMD} add allow icmp from any to any via ${LanIn} ${FwCMD} add deny ip from any to any ${FwCMD} add allow tcp from 192.168.0.1 to me 22 via ${LanIn} ${FwCMD} add allow tcp from me 22 to 192.168.0.1 via ${LanIn} С 71EB лучше не будет, тут дело не в карте вовсе. Ну не знаю, на тех трех серверах карточки с этим же чипсетом Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 6 апреля, 2012 · Жалоба mpd используем для раздачи туннелями, шейпим им же, как он через нетграф это делает, я не исследовал, файрволл - ${FwCMD} -f flush ${FwCMD} add allow ip from any to any via lo0 ${FwCMD} add deny ip from any to 127.0.0.0/8 ${FwCMD} add deny ip from 127.0.0.0/8 to any .. Про файрволл без комментариев, выше все написано. Ну не знаю, на тех трех серверах карточки с этим же чипсетом Тут, скорее, забава вот в чем: #if __FreeBSD_version >= 800000 rxr->fmp->m_pkthdr.flowid = que->msix; rxr->fmp->m_flags |= M_FLOWID; #endif © sys/dev/e1000/if_igb.c То есть для всего non-ip трафика всем пакетам выставляется нулевая очередь. Можно это просто вынести из драйвера, можно патч применить и выкрутить dev.igb.X.use_flowid=0 на тех картах, где бегает PPPoE. Патч вот: http://static.ipfw.ru/patches/e1000_flowid.diff Ну и да, если лучше не станет (да и вообще, в любом случае) интересно взглянуть на netstat -Q, netstat -B, systat -vm 1 или top -HSP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 6 апреля, 2012 · Жалоба Спасибо, посмотрим Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
В Густелёв Опубликовано 11 апреля, 2012 (изменено) · Жалоба Ага, уже лучше. А если клиенты реально только за igb0 и там нет вланов - то еще проще, например как-то так: allow ip from any to any via igb0 (на входе от клиента мы не натим, на выходе в него - тоже) skipto 500 ip from any to any out 00007 143928863 49229232396 setfib 2 ip from table(91) to any 00008 16410435 5024164499 setfib 3 ip from table(71) to any 00110 176067271 85046336428 nat tablearg ip from any to table(X) allow ip from any to any 00550 33536343 12997457095 nat tablearg ip from table(X+1) to any 65535 387265807 175454005095 allow ip from any to any я еще setfib перенес после 500го правила - он же только для исходящего трафика, это сразу дает еще процентов по 5 на ядра. добавить allow ip from any to any via igb0 первым правилом не работает, и я чтото сегодня уже не соображаю почему в итоге сейчас: ipfw list 00005 skipto 350 ip from table(81) to any 00010 skipto 200 ip from any to any out 00110 nat tablearg ip from any to table(92) in recv vlan136 00130 nat tablearg ip from any to table(72) in recv igb1 00140 nat tablearg ip from any to table(82) in recv vlan134 00200 setfib 2 ip from table(91) to any 00210 setfib 3 ip from table(71) to any 00350 nat tablearg ip from table(81) to any out xmit vlan134 00390 nat tablearg ip from table(91) to any out xmit vlan136 00392 nat tablearg ip from table(71) to any out xmit igb1 65535 allow ip from any to any и нагрузка: last pid: 35988; load averages: 0.05, 0.09, 0.09 up 7+22:42:45 01:45:03 126 processes: 6 running, 90 sleeping, 30 waiting CPU 0: 0.0% user, 0.0% nice, 1.1% system, 32.7% interrupt, 66.2% idle CPU 1: 0.0% user, 0.0% nice, 1.1% system, 36.5% interrupt, 62.4% idle CPU 2: 0.0% user, 0.0% nice, 1.1% system, 38.3% interrupt, 60.5% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 42.1% interrupt, 57.9% idle Mem: 18M Active, 192M Inact, 681M Wired, 316K Cache, 417M Buf, 3030M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU3 3 112.1H 67.19% {idle: cpu3} 11 root 171 ki31 0K 64K CPU1 1 111.3H 63.96% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 0 110.8H 61.77% {idle: cpu0} 11 root 171 ki31 0K 64K RUN 2 111.5H 60.60% {idle: cpu2} 12 root -68 - 0K 496K CPU2 2 60.2H 35.35% {irq263: igb1:que 12 root -68 - 0K 496K WAIT 3 60.1H 33.25% {irq264: igb1:que 12 root -68 - 0K 496K WAIT 0 60.2H 32.08% {irq261: igb1:que 12 root -68 - 0K 496K WAIT 1 60.1H 31.05% {irq262: igb1:que 12 root -68 - 0K 496K WAIT 2 958:44 5.96% {irq258: igb0:que 12 root -68 - 0K 496K WAIT 1 953:18 5.57% {irq257: igb0:que 12 root -68 - 0K 496K WAIT 0 957:27 5.27% {irq256: igb0:que 12 root -68 - 0K 496K WAIT 3 953:13 4.88% {irq259: igb0:que 0 root -68 0 0K 240K - 0 121:29 0.59% {igb1 que} 0 root -68 0 0K 240K - 3 109:11 0.49% {igb1 que} до STABLE пока не обновлялся и заморочки с setfib не пробовал, которые ты предлагаешь Изменено 11 апреля, 2012 пользователем В Густелёв Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
В Густелёв Опубликовано 21 ноября, 2012 · Жалоба Коллеги, поднимаю тему. Прошло полгода, и вот у меня снова есть подозрения на проблемы: netstat 472K 0 0 198M 459K 0 141M 0 467K 0 0 194M 455K 0 139M 0 303K 167 0 144M 297K 0 106M 0 401K 0 0 183M 389K 0 131M 0 454K 0 0 186M 442K 0 135M 0 454K 0 0 183M 443K 0 132M 0 last pid: 14528; load averages: 0.42, 0.42, 0.36 up 0+04:23:51 16:40:31121 processes: 12 running, 84 sleeping, 25 waiting CPU 0: 0.0% user, 0.0% nice, 3.4% system, 64.7% interrupt, 32.0% idle CPU 1: 0.0% user, 0.0% nice, 4.1% system, 69.3% interrupt, 26.6% idle CPU 2: 0.0% user, 0.0% nice, 7.1% system, 59.2% interrupt, 33.7% idle CPU 3: 0.0% user, 0.0% nice, 3.4% system, 62.4% interrupt, 34.2% idle Mem: 15M Active, 17M Inact, 391M Wired, 88K Cache, 417M Buf, 3499M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -68 - 0K 496K CPU1 1 128:11 59.67% {irq262: igb1:que 12 root -68 - 0K 496K WAIT 0 129:05 56.79% {irq261: igb1:que 12 root -68 - 0K 496K CPU3 3 130:09 56.30% {irq264: igb1:que 12 root -68 - 0K 496K RUN 2 131:39 55.08% {irq263: igb1:que 11 root 171 ki31 0K 64K RUN 2 91:03 33.40% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 3 91:01 32.47% {idle: cpu3} 11 root 171 ki31 0K 64K RUN 1 92:57 30.27% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 0 90:41 28.17% {idle: cpu0} 12 root -68 - 0K 496K WAIT 0 18:45 10.35% {irq256: igb0:que 12 root -68 - 0K 496K RUN 1 17:59 9.57% {irq257: igb0:que 12 root -68 - 0K 496K RUN 3 18:58 9.28% {irq259: igb0:que 12 root -68 - 0K 496K RUN 2 17:05 9.18% {irq258: igb0:que 0 root -68 0 0K 240K - 1 24:22 4.20% {igb1 que} 0 root -68 0 0K 240K CPU2 1 22:41 3.27% {igb1 que} >ipfw show00010 1280325298 1011957457414 allow ip from any to any via igb0 00100 2529193158 377199407963 skipto 200 ip from any to any out 00110 2663347047 1002949265477 nat tablearg ip from any to table(72) in recv vlan158 00120 6848953 446514172 allow ip from any to any 00200 585550277 197252837190 nat tablearg ip from table(71) to any out xmit vlan158 65535 2021499042 192514206892 allow ip from any to any В принципе, может быть ничего криминального и нет - трафик и PPS увеличился на половину, а нагрузка выросла примерно на 30% Сообщите, я упираюсь в мощность сервера или можно еще крутануть какую-то задвижку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 ноября, 2012 · Жалоба net.isr.direct пораспихать по очередям и всё, чтобы пакеты обрабатывались в isr потоках а не в прерываниях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
В Густелёв Опубликовано 21 ноября, 2012 · Жалоба net.isr.direct пораспихать по очередям и всё, чтобы пакеты обрабатывались в isr потоках а не в прерываниях. net.isr.direct: 1 включено вроде. Расскажи подробнее об этом, пожалуйста? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 21 ноября, 2012 (изменено) · Жалоба Вот мои параметры. Вообщем замечена такая проблема. Спустя несколько дней прерывания начинают расти, хотя PPS и трафик не растет. пока не понял почему такое. Для сравнения вот параметры. Используем FreeBSD 9.1 MPD5 . Терминируются PPPoE Шейпер NG_car. Нат на другой машине. Две карты Intel 82576 2-х портовые каждая объединена в lagg . lagg0(2,3) в сторону аплинка. lagg1(igb0,1)(100 вланов ) каждый влан слушает PPPoE hw.model: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz top -SHP pppoe2# top -SHP last pid: 14933; load averages: 2.07, 1.59, 1.60 up 0+12:00:38 17:26:48 156 processes: 6 running, 112 sleeping, 38 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 30.8% interrupt, 69.2% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 23.1% interrupt, 76.9% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 46.2% interrupt, 53.8% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 38.5% interrupt, 61.5% idle Mem: 50M Active, 34M Inact, 386M Wired, 27M Buf, 3471M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K RUN 0 622:24 72.85% idle{idle: cpu0} 11 root 155 ki31 0K 64K RUN 1 606:14 71.48% idle{idle: cpu1} 11 root 155 ki31 0K 64K CPU3 3 601:49 70.17% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 2 595:32 67.97% idle{idle: cpu2} 12 root -92 - 0K 624K WAIT 1 102:12 30.47% intr{irq261: igb1:que} 12 root -92 - 0K 624K CPU0 0 83:52 27.10% intr{irq256: igb0:que} 12 root -92 - 0K 624K WAIT 2 24:56 8.06% intr{irq269: igb2:que} 12 root -92 - 0K 624K WAIT 3 24:34 7.67% intr{irq272: igb3:que} 12 root -92 - 0K 624K WAIT 3 23:12 7.67% intr{irq271: igb3:que} 12 root -92 - 0K 624K WAIT 3 23:55 6.98% intr{irq274: igb3:que} 12 root -92 - 0K 624K WAIT 3 24:08 6.79% intr{irq273: igb3:que} 12 root -92 - 0K 624K WAIT 2 31:11 6.30% intr{irq266: igb2:que} 12 root -92 - 0K 624K WAIT 2 22:58 6.05% intr{irq267: igb2:que} 12 root -92 - 0K 624K WAIT 2 22:12 5.27% intr{irq268: igb2:que} 10534 root 26 0 37596K 8948K select 3 23:41 4.98% snmpd 10821 root 22 0 102M 51180K select 3 20:15 2.88% mpd5{mpd5} 10821 root 22 0 102M 51180K select 2 0:00 2.88% mpd5{mpd5} 10821 root 22 0 102M 51180K select 2 0:00 2.78% mpd5{mpd5} 12 root -92 - 0K 624K WAIT 2 4:59 0.88% intr{irq259: igb0:que} 12 root -92 - 0K 624K WAIT 3 4:16 0.68% intr{irq263: igb1:que} 12 root -92 - 0K 624K WAIT 2 4:30 0.59% intr{irq258: igb0:que} 12 root -92 - 0K 624K WAIT 3 4:03 0.59% intr{irq264: igb1:que} 0 root -16 0 0K 400K sched 2 1:50 0.00% kernel{swapper} 10404 root 20 0 12184K 1632K select 1 0:40 0.00% syslogd 12 root -60 - 0K 624K WAIT 2 0:32 0.00% intr{swi4: clock} 0 root -92 0 0K 400K - 3 0:14 0.00% kernel{igb2 que} ifconfig | grep ng -c 972 pppoe2# netstat -w1 -h input (Total) output packets errs idrops bytes packets errs bytes colls 235k 0 0 164M 254k 0 234M 0 183k 0 0 163M 184k 0 152M 0 239k 0 0 167M 260k 0 240M 0 247k 0 0 172M 268k 0 251M 0 pppoe2# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq17: atapci0+ 87862 2 irq22: uhci2 ehci0* 24 0 cpu0:timer 44180834 1015 irq256: igb0:que 0 291175461 6693 irq257: igb0:que 1 254742 5 irq258: igb0:que 2 177976667 4091 irq259: igb0:que 3 187295516 4305 irq260: igb0:link 2 0 irq261: igb1:que 0 327530388 7528 irq262: igb1:que 1 656468 15 irq263: igb1:que 2 163597776 3760 irq264: igb1:que 3 164811436 3788 irq265: igb1:link 3 0 irq266: igb2:que 0 441352433 10145 irq267: igb2:que 1 84079581 1932 irq268: igb2:que 2 80890558 1859 irq269: igb2:que 3 90910985 2089 irq270: igb2:link 2 0 irq271: igb3:que 0 88241302 2028 irq272: igb3:que 1 91720474 2108 irq273: igb3:que 2 90205996 2073 irq274: igb3:que 3 86750451 1994 irq275: igb3:link 3 0 irq276: bge0 560890 12 cpu1:timer 43026353 989 cpu3:timer 46119852 1060 cpu2:timer 46678893 1072 Total 2548104958 58571 Изменено 21 ноября, 2012 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 ноября, 2012 · Жалоба net.isr.direct: 1включено вроде. Расскажи подробнее об этом, пожалуйста? Когда директ включён, то сетевуха генерит прерываание о том что данные получены, и система начинает обрабатывать полученные данные прямо в из обработчика этого прерывания. Когда выключено, то во время прерывания полученные данные ставятся в специальную очередь и на этом работы обработчика прерываний заканчивается. Данные из очереди обрабатывают isr потоки, которых запущено по количеству ядер и они прибиты к ядрам. В 9.х крутилки чуточку поменяли название и net.isr.direct (+форс крутилка) стал только для чтения, а крутится через: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=4096 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero Как работает гибрид вариант - я хз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 22 ноября, 2012 · Жалоба net.isr.direct: 1включено вроде. Расскажи подробнее об этом, пожалуйста? Когда директ включён, то сетевуха генерит прерываание о том что данные получены, и система начинает обрабатывать полученные данные прямо в из обработчика этого прерывания. Когда выключено, то во время прерывания полученные данные ставятся в специальную очередь и на этом работы обработчика прерываний заканчивается. Данные из очереди обрабатывают isr потоки, которых запущено по количеству ядер и они прибиты к ядрам. В 9.х крутилки чуточку поменяли название и net.isr.direct (+форс крутилка) стал только для чтения, а крутится через: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=4096 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero Как работает гибрид вариант - я хз. гибрид работает как гибрид, и директом и дефером :) Если поток netisr на том-же ядре что и обработчик прерывания пакет в очередь не ставится и обрабатывается в обработчике прерывания, тоесть получается директ. Если же netisr считает, что пакет будет обрабатываться на другом ядре он ставится в очередь и ждет там пока трид netisr на нужном ядре не освободится, тоесть получается дефер. Теоретически нет смысла ставить пакет в очередь и потом доставать его оттуда только для того, чтобы разбудить поток netisr на том-же ядре, можно протолкнуть пакет прямо в обработчике прерывания. Это то, что я понял из исходников netisr, но там немного магии есть, а у меня скилы такие заклинания не тянут. Кстати где-то проскакивала инфа, что очереди netisr собирались переписать на ringbuff, типа это заметно уменьшит overhead от постановки в очередь/выемки из очереди, но я хз как там процесс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 23 ноября, 2012 (изменено) · Жалоба В час пик . Вот скока смог выжить. NAT - на отдельной тачке . netfow нет. тупо терминация pppoe и шейпер. Ну и фаер , ipfw table для управление доступоп пользователей процессор pppoe2# sysctl -a | grep hw.mode hw.model: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz lagg0 igb1,igb2 lagg1 igb0,igb1 +100 vlan-во слушает MPD(PPPoE) Количество сессий pppoe2# ifconfig | grep ng -c 1936 top -SHPI last pid: 18583; load averages: 3.71, 3.59, 3.41 up 2+16:14:03 21:40:13 159 processes: 8 running, 115 sleeping, 36 waiting CPU 0: 1.6% user, 0.4% nice, 0.4% system, 62.4% interrupt, 35.3% idle CPU 1: 0.8% user, 0.0% nice, 0.0% system, 91.0% interrupt, 8.2% idle CPU 2: 6.3% user, 1.6% nice, 0.8% system, 36.5% interrupt, 54.9% idle CPU 3: 3.9% user, 1.2% nice, 1.6% system, 41.6% interrupt, 51.8% idle Mem: 115M Active, 289M Inact, 690M Wired, 417M Buf, 2845M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -92 - 0K 624K CPU1 1 18.5H 89.99% intr{irq261: igb1:que} 12 root -92 - 0K 624K WAIT 0 17.4H 68.36% intr{irq256: igb0:que} 11 root 155 ki31 0K 64K RUN 2 47.4H 53.66% idle{idle: cpu2} 11 root 155 ki31 0K 64K RUN 3 48.1H 50.98% idle{idle: cpu3} 11 root 155 ki31 0K 64K RUN 0 45.4H 28.47% idle{idle: cpu0} 10534 root 35 0 37596K 10580K select 3 225:38 12.89% snmpd 12 root -92 - 0K 624K WAIT 2 187:43 11.28% intr{irq268: igb2:que} 12 root -92 - 0K 624K WAIT 2 245:03 9.96% intr{irq266: igb2:que} 12 root -92 - 0K 624K CPU2 2 192:16 9.96% intr{irq269: igb2:que} 12 root -92 - 0K 624K WAIT 3 191:49 9.86% intr{irq271: igb3:que} 12 root -92 - 0K 624K WAIT 3 185:11 9.38% intr{irq272: igb3:que} 12 root -92 - 0K 624K WAIT 3 190:20 9.28% intr{irq273: igb3:que} 12 root -92 - 0K 624K WAIT 2 190:09 9.18% intr{irq267: igb2:que} 12 root -92 - 0K 624K CPU3 3 193:45 8.79% intr{irq274: igb3:que} 11 root 155 ki31 0K 64K RUN 1 44.4H 8.06% idle{idle: cpu1} 7157 root 24 2 170M 112M select 3 90:42 3.37% mpd5{mpd5} 0 root -92 0 0K 400K - 2 1:56 2.69% kernel{igb1 que} 12 root -92 - 0K 624K WAIT 2 33:37 1.17% intr{irq259: igb0:que} 12 root -92 - 0K 624K WAIT 3 33:03 0.78% intr{irq263: igb1:que} 12 root -92 - 0K 624K WAIT 2 30:21 0.78% intr{irq258: igb0:que} 12 root -92 - 0K 624K WAIT 3 30:36 0.59% intr{irq264: igb1:que} netstat -w1 -h pppoe2# netstat -w1 -h input (Total) output packets errs idrops bytes packets errs bytes colls 470k 0 0 320M 516k 0 457M 0 478k 0 0 326M 526k 0 472M 0 482k 0 0 327M 531k 0 473M 0 487k 0 0 330M 536k 0 475M 0 448k 0 0 300M 490k 0 426M 0 464k 0 0 319M 504k 0 446M 0 vmstat -i pppoe2# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq17: atapci0+ 772049 3 irq22: uhci2 ehci0* 24 0 cpu0:timer 249780170 1079 irq256: igb0:que 0 1789026240 7730 irq257: igb0:que 1 2158010 9 irq258: igb0:que 2 1130172082 4883 irq259: igb0:que 3 1188234638 5134 irq260: igb0:link 2 0 irq261: igb1:que 0 1761698070 7612 irq262: igb1:que 1 3517710 15 irq263: igb1:que 2 1127301372 4871 irq264: igb1:que 3 1136757872 4911 irq265: igb1:link 3 0 irq266: igb2:que 0 2487989583 10750 irq267: igb2:que 1 614817850 2656 irq268: igb2:que 2 607654603 2625 irq269: igb2:que 3 626207562 2705 irq270: igb2:link 2 0 irq271: igb3:que 0 626248740 2706 irq272: igb3:que 1 617059969 2666 irq273: igb3:que 2 628935390 2717 irq274: igb3:que 3 634822829 2743 irq275: igb3:link 3 0 irq276: bge0 4346664 18 cpu1:timer 245262642 1059 cpu3:timer 257367529 1112 cpu2:timer 258164615 1115 Total 15998296229 69128 Изменено 23 ноября, 2012 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 30 ноября, 2012 (изменено) · Жалоба И проблема заключается в том , на след день и далее , прерывания растут , хотя трафик и pps не изменился. У меня lagg1 объеденены igb2 и igb3 . lagg1 слушает MPD. Не могу понять почему . В первый день хоть 1500 мбит отмочит. last pid: 1123; load averages: 2.45, 2.42, 2.40 up 3+13:06:51 23:03:46 165 processes: 6 running, 120 sleeping, 39 waiting CPU 0: 6.8% user, 0.0% nice, 1.4% system, 26.0% interrupt, 65.8% idle CPU 1: 11.0% user, 0.0% nice, 2.7% system, 21.9% interrupt, 64.4% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 90.4% interrupt, 9.6% idle CPU 3: 2.7% user, 0.0% nice, 0.0% system, 54.8% interrupt, 42.5% idle Mem: 190M Active, 377M Inact, 941M Wired, 622M Buf, 4419M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 12 root -92 - 0K 640K CPU2 2 31.1H 89.79% [intr{irq266: igb2:que}] 11 root 155 ki31 0K 64K RUN 1 67.9H 78.08% [idle{idle: cpu1}] 11 root 155 ki31 0K 64K CPU0 0 67.0H 74.56% [idle{idle: cpu0}] 12 root -92 - 0K 640K WAIT 3 33.6H 63.28% [intr{irq271: igb3:que}] 11 root 155 ki31 0K 64K CPU3 3 49.1H 38.96% [idle{idle: cpu3}] 11 root 155 ki31 0K 64K CPU2 2 51.7H 11.87% [idle{idle: cpu2}] 12 root -92 - 0K 640K WAIT 1 218:15 6.79% [intr{irq261: igb1:que}] 12 root -92 - 0K 640K WAIT 0 196:23 5.86% [intr{irq257: igb0:que}] 12 root -92 - 0K 640K WAIT 0 203:58 5.66% [intr{irq264: igb1:que}] 12 root -92 - 0K 640K WAIT 0 259:40 5.37% [intr{irq256: igb0:que}] 87666 root 23 0 37596K 11568K select 2 159:39 4.69% /usr/local/sbin/snmpd -p /var/run/net_snmpd.pid 12 root -92 - 0K 640K WAIT 1 196:17 4.39% [intr{irq262: igb1:que}] 12 root -92 - 0K 640K WAIT 1 200:30 3.96% [intr{irq258: igb0:que}] 12 root -92 - 0K 640K WAIT 1 203:01 3.37% [intr{irq259: igb0:que}] 12 root -92 - 0K 640K WAIT 0 200:45 2.88% [intr{irq263: igb1:que}] 12666 root 21 0 488M 235M select 1 170:03 1.07% /usr/local/sbin/mpd5 -p /var/run/mpd5.pid -b{mpd5} 0 root -92 0 0K 400K - 1 5:40 0.49% [kernel{igb2 que}] 12 root -92 - 0K 640K WAIT 0 37:14 0.29% [intr{irq267: igb2:que}] 12 root -92 - 0K 640K WAIT 1 33:29 0.20% [intr{irq272: igb3:que}] netstat -w1 -h pppoe2# netstat -w1 -h input (Total) output packets errs idrops bytes packets errs bytes colls 241k 0 0 169M 253k 0 225M 0 231k 0 0 158M 243k 0 215M 0 237k 0 0 164M 248k 0 219M 0 0 0 -58M 0 0 232k 0 0 163M 242k 0 212M 0 228k 0 0 156M 242k 0 216M 0 Изменено 30 ноября, 2012 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 июня, 2015 · Жалоба Обнаружил похожие симптомы у себя на 10.1: IGB и таймер прерывания в полку грузят проц. Тачка потребляет трафик (больше гига в юзерспейс софтину). Началось после того как два IGB объединил в lagg, до того всё нормально было. Притом проблема вылезает даже если траф пустить через em адаптер а по лагг только ссш. pmcstat -TS instructions -w1 показывал затык в локе на igmp (я только принимал гиг мультикаста, не отправлял). На домашнем стенде не воспроизвелось: либо потому что было em+re вместо igb либо проц+чипсет другие. Там где оно было - дебажить крайне не удобно, оно уже используется. Обошёл просто - собрал lagg средствами нетграфа. Если интересно - могу поделится скриптом для сборки lagg из нетграфа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 21 июня, 2015 · Жалоба Обошёл просто - собрал lagg средствами нетграфа. Если интересно - могу поделится скриптом для сборки lagg из нетграфа. Прошу вас :) И можно ли на такой лагг вешать netflow средствами ng_*? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 июня, 2015 · Жалоба Ок, оформлю у себя в вики и закину линк. И можно ли на такой лагг вешать netflow средствами ng_*? Можно. Повешать ng_hub в разрыв и туда зацепить. При некотором желании можно даже адаптеры из системы не "терять", но учитывая что в коммутаторе они объединены это смысла не имеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 23 июня, 2015 · Жалоба Так где скрипт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 июня, 2015 · Жалоба http://www.netlab.linkpc.net/wiki/ru:software:freebsd:lagg_on_netgraph Красоту не наводил, все имена зашиты. По хорошему надо бы накидать было скрипт типа rc.d который в параметрах бы принимал названия интерфесов физических и интерфейса лагг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 июня, 2015 · Жалоба Ок. Приму к сведению. Но без балансировки нагрузки - это плохой LAGG. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 июня, 2015 · Жалоба Там round robin пер пакет на исход. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 июля, 2015 · Жалоба Теперь и в виде нормального скрипта: http://www.netlab.linkpc.net/wiki/ru:software:freebsd:lagg_on_netgraph Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 20 июля, 2015 · Жалоба Чем отличаются lagg0 от xyzlagg ? Названия lagg - case sensitive? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 июля, 2015 · Жалоба Названием, там можно было вообще что угодно написать, лишь бы не слишком длинное и без точек и двоеточий в названии. У меня было и "test", на работоспособности это не сказывается. Изначально создаётся ngeth0 (или другой цифрой) интерфейс, а потом он переименовывается с помощью ifconfig name вместе с нодами. Чувствительность к регистру не проверял, думаю регистр важен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...