ichthyandr Опубликовано 7 марта, 2012 · Жалоба у нас непонятки - есть 3 бокса с бсд 7.3 и поставили новый с бсд 9.0 на 7.3 - стоят адаптеры emX на 9.0 - igbX насы раздают инет через pptp/l2tp, в результате бокс под 9-кой не может достичь пика количества сессий, как у боксов на 7.3 top -SHPI на 7.3 last pid: 8675; load averages: 0.71, 0.73, 0.67 up 168+01:00:20 11:05:10 112 processes: 9 running, 84 sleeping, 19 waiting CPU 0: 1.5% user, 0.0% nice, 9.0% system, 0.0% interrupt, 89.5% idle CPU 1: 1.5% user, 0.0% nice, 10.5% system, 0.0% interrupt, 88.0% idle CPU 2: 1.1% user, 0.0% nice, 3.8% system, 0.0% interrupt, 95.1% idle CPU 3: 0.4% user, 0.0% nice, 2.3% system, 0.0% interrupt, 97.4% idle CPU 4: 0.0% user, 0.0% nice, 3.0% system, 0.0% interrupt, 97.0% idle CPU 5: 0.0% user, 0.0% nice, 6.0% system, 0.4% interrupt, 93.6% idle CPU 6: 0.0% user, 0.0% nice, 8.3% system, 0.0% interrupt, 91.7% idle CPU 7: 0.0% user, 0.0% nice, 7.1% system, 0.0% interrupt, 92.9% idle Mem: 2152M Active, 145M Inact, 1232M Wired, 188K Cache, 1919M Buf, 20G Free Swap: 32G Total, 32G Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 16K RUN 7 3550.0 100.00% idle: cpu7 16 root 171 ki31 0K 16K CPU2 2 3408.3 98.14% idle: cpu2 14 root 171 ki31 0K 16K CPU4 4 3589.0 96.68% idle: cpu4 15 root 171 ki31 0K 16K CPU3 3 3529.9 96.24% idle: cpu3 12 root 171 ki31 0K 16K CPU6 6 3423.2 93.51% idle: cpu6 18 root 171 ki31 0K 16K CPU0 0 3171.6 93.51% idle: cpu0 13 root 171 ki31 0K 16K CPU5 5 3410.4 92.14% idle: cpu5 17 root 171 ki31 0K 16K CPU1 1 3263.6 88.92% idle: cpu1 41 root -68 - 0K 16K - 6 536.2H 7.71% em1 taskq 40 root -68 - 0K 16K - 5 533.3H 5.27% em0 taskq 44691 root 46 0 2288M 2251M select 1 267.1H 4.69% mpd5 42 root -68 - 0K 16K - 7 393.1H 4.44% em2 taskq 6 root -68 - 0K 16K sleep 1 275.8H 2.88% ng_queue4 8 root -68 - 0K 16K sleep 1 276.2H 2.59% ng_queue6 2 root -68 - 0K 16K sleep 1 276.1H 2.54% ng_queue0 37290 root 45 0 8912K 4836K select 0 156.9H 2.49% routed 5 root -68 - 0K 16K sleep 2 276.2H 2.44% ng_queue3 7 root -68 - 0K 16K sleep 2 276.0H 2.44% ng_queue5 4 root -68 - 0K 16K sleep 4 276.2H 2.34% ng_queue2 9 root -68 - 0K 16K sleep 0 275.7H 2.34% ng_queue7 43 root -68 - 0K 16K - 0 345.1H 2.29% em3 taskq 3 root -68 - 0K 16K sleep 3 276.6H 2.25% ng_queue1 top -SHPI на 9.0 last pid: 1540; load averages: 0.63, 0.60, 0.59 up 0+18:01:22 11:06:56 165 processes: 11 running, 114 sleeping, 40 waiting CPU 0: 1.2% user, 0.0% nice, 4.7% system, 9.4% interrupt, 84.6% idle CPU 1: 1.2% user, 0.0% nice, 6.3% system, 3.5% interrupt, 89.0% idle CPU 2: 0.4% user, 0.0% nice, 3.9% system, 3.1% interrupt, 92.5% idle CPU 3: 3.5% user, 0.0% nice, 3.1% system, 3.9% interrupt, 89.4% idle CPU 4: 0.0% user, 0.0% nice, 10.2% system, 1.6% interrupt, 88.2% idle CPU 5: 0.0% user, 0.0% nice, 7.9% system, 0.8% interrupt, 91.3% idle CPU 6: 1.2% user, 0.0% nice, 3.5% system, 4.7% interrupt, 90.6% idle CPU 7: 0.4% user, 0.0% nice, 0.0% system, 4.3% interrupt, 95.3% idle Mem: 29M Active, 46M Inact, 853M Wired, 80K Cache, 1424M Buf, 22G Free Swap: 4068M Total, 4068M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 128K CPU2 2 17.1H 98.44% idle{idle: cpu2} 11 root 155 ki31 0K 128K CPU0 0 985:08 98.39% idle{idle: cpu0} 11 root 155 ki31 0K 128K CPU3 3 17.4H 96.83% idle{idle: cpu3} 11 root 155 ki31 0K 128K RUN 1 993:50 96.78% idle{idle: cpu1} 11 root 155 ki31 0K 128K RUN 6 17.1H 96.44% idle{idle: cpu6} 11 root 155 ki31 0K 128K CPU7 7 17.3H 95.21% idle{idle: cpu7} 11 root 155 ki31 0K 128K CPU5 5 16.7H 91.41% idle{idle: cpu5} 11 root 155 ki31 0K 128K CPU4 4 987:33 89.84% idle{idle: cpu4} 13 root -16 - 0K 128K sleep 4 28:42 3.03% ng_queue{ng_queue7} 13 root -16 - 0K 128K sleep 6 28:46 2.93% ng_queue{ng_queue2} 13 root -16 - 0K 128K sleep 5 28:42 2.83% ng_queue{ng_queue1} 13 root -16 - 0K 128K RUN 1 28:44 2.78% ng_queue{ng_queue5} 13 root -16 - 0K 128K sleep 5 28:50 2.73% ng_queue{ng_queue6} 13 root -16 - 0K 128K sleep 2 28:42 2.73% ng_queue{ng_queue4} 13 root -16 - 0K 128K sleep 3 28:49 2.69% ng_queue{ng_queue3} 13 root -16 - 0K 128K sleep 4 28:49 2.54% ng_queue{ng_queue0} 12 root -92 - 0K 656K WAIT 0 21:58 2.54% intr{irq272: igb1:que} 12 root -92 - 0K 656K WAIT 2 13:03 2.00% intr{irq258: igb0:que} 12 root -92 - 0K 656K WAIT 6 15:16 1.90% intr{irq262: igb0:que} 12 root -92 - 0K 656K WAIT 7 17:32 1.86% intr{irq263: igb0:que} 12 root -92 - 0K 656K WAIT 1 23:01 1.76% intr{irq265: igb1:que} 12 root -92 - 0K 656K WAIT 0 14:41 1.71% intr{irq256: igb0:que} 12 root -92 - 0K 656K WAIT 4 15:00 1.56% intr{irq268: igb1:que} 12 root -92 - 0K 656K WAIT 5 14:12 1.46% intr{irq261: igb0:que} 12 root -92 - 0K 656K WAIT 1 15:18 1.37% intr{irq257: igb0:que} 12 root -92 - 0K 656K CPU4 4 15:10 1.37% intr{irq260: igb0:que} 12 root -92 - 0K 656K WAIT 3 15:44 1.12% intr{irq259: igb0:que} 12 root -92 - 0K 656K WAIT 7 9:47 0.93% intr{irq271: igb1:que} 1271 root 21 0 148M 33672K select 4 16:55 0.83% mpd5{mpd5} vmstat -i на 7.3 nas27# vmstat -i interrupt total rate irq3: sio1 2 0 irq4: sio0 2 0 irq14: ata0 82 0 irq16: mfi0 11207248 0 irq17: uhci0 uhci2+ 467 0 irq19: ehci0 uhci4 3 0 cpu0: timer 29039229294 2000 irq256: bce0 1 0 irq257: bce1 1 0 irq258: em0 88723847820 6110 irq259: em1 88816403454 6117 irq260: em2 90256811508 6216 irq261: em3 90166353286 6210 cpu1: timer 29039220798 2000 cpu6: timer 29039220797 2000 cpu2: timer 29039220798 2000 cpu4: timer 29039220797 2000 cpu3: timer 29039220798 2000 cpu7: timer 29039220798 2000 cpu5: timer 29039220798 2000 Total 590288398752 40656 vmstat -i на 9.0 nas26# vmstat -i interrupt total rate irq14: ata0 19 0 irq15: ata1 1 0 irq16: mfi0 117031 1 irq17: uhci0 uhci2+ 36 0 irq19: ehci0 uhci4 2 0 cpu0:timer 138141593 2125 irq256: igb0:que 0 123316034 1897 irq257: igb0:que 1 127185514 1956 irq258: igb0:que 2 110521829 1700 irq259: igb0:que 3 157187430 2418 irq260: igb0:que 4 119176680 1833 irq261: igb0:que 5 104526457 1608 irq262: igb0:que 6 128335085 1974 irq263: igb0:que 7 205123094 3156 irq264: igb0:link 2 0 irq265: igb1:que 0 454699579 6996 irq266: igb1:que 1 66510564 1023 irq267: igb1:que 2 62750649 965 irq268: igb1:que 3 109081855 1678 irq269: igb1:que 4 58601295 901 irq270: igb1:que 5 49487164 761 irq271: igb1:que 6 74461792 1145 irq272: igb1:que 7 159580647 2455 irq273: igb1:link 2 0 cpu1:timer 135112444 2078 cpu6:timer 108184320 1664 cpu2:timer 118422473 1822 cpu5:timer 122401077 1883 cpu3:timer 100787711 1550 cpu7:timer 121186830 1864 cpu4:timer 131599405 2024 Total 3086498614 47488 сдается мне с сетевухой на 9.0 чтото делать надо, есть у кого какие мысли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 7 марта, 2012 · Жалоба Что означает - пик количества сессий? Количество авторизованных абонентов или установленных tcp-соединений? vmstat просто показывает прерывания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 7 марта, 2012 · Жалоба Что означает - пик количества сессий? Количество авторизованных абонентов или установленных tcp-соединений? vmstat просто показывает прерывания. количество установленных ppp соединений, т.е на каждом c 7.3 по ~900, на 9.0 ~600, хотя dns все насы отдает равномерно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 7 марта, 2012 · Жалоба Вобщем я переработал секцию свою вот так: 10000 4093424 4164152915 Wed Mar 7 15:54:55 2012 allow ip from any to not me in recv igb1 10001 280390 71526402 Wed Mar 7 15:54:55 2012 allow ip from table(3) to any out xmit igb1 10005 7719146 5372732262 Wed Mar 7 15:54:55 2012 allow ip from any to any via ng* Последней строкой открываем трубу для всех ng-нод, первой строкой разрешаем входящий трафик на внешний интерфейс для всех адресов назначения кроме тех, которые назначены непосредственно на igb1 и второй строчкой делаем рестрикции для пользователей с отрицательным балансом отфильтровывая их еще перед nat-трансляцией. Как видно по счетчикам, table3 с 5к записями используется в том месте, где количество совпадений минимально. Вроде оптимизировать эту часть уже некуда. Этим постом я запускаю новый отчет бесперебойной работы сервера доступа. Что означает - пик количества сессий? Количество авторизованных абонентов или установленных tcp-соединений? vmstat просто показывает прерывания. количество установленных ppp соединений, т.е на каждом c 7.3 по ~900, на 9.0 ~600, хотя dns все насы отдает равномерно Времени больше суток прошло? Может быть юзеры специально дисконнектятся от 9.0 так как ощущают лаги в работе (если они есть). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 7 марта, 2012 · Жалоба Времени больше суток прошло? Может быть юзеры специально дисконнектятся от 9.0 так как ощущают лаги в работе (если они есть). месяц работал, адрес насов выдается как vpn.траляля, обратил внимание на то, что при подключении пользователя туннель может сбросится, хотя по нетстату ошибок вроде нет, единственно что обращает на себя внимание под 9.0 с igb карточкой - большее время на обработку прерываний Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 7 марта, 2012 · Жалоба Следует частоту этих сбросов выявить, может в этом и есть причина. С l2tp или pppoe никогда не работал, зато к пятой ветке mpd вобще никаких претензий нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 7 марта, 2012 (изменено) · Жалоба ichthyandr, рекомендую использовать top с ключами -aSCHIP, вывод будет существенно более короткий и ёмкий. А что показывает у вас команда sysctl dev.igb| fgrep -v ": 0"? 9.0 с igb карточкой - большее время на обработку прерываний Э-э-э...вы не поясните, что вы имелив виду? Изменено 7 марта, 2012 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 7 марта, 2012 · Жалоба ichthyandr, рекомендую использовать top с ключами -aSCHIP, вывод будет существенно более короткий и ёмкий. А что показывает у вас команда sysctl dev.igb| fgrep -v ": 0"? 9.0 с igb карточкой - большее время на обработку прерываний Э-э-э...вы не поясните, что вы имелив виду? бокс, бсд 7.3, адаптеры em last pid: 67534; load averages: 1.18, 1.28, 1.22 up 168+06:25:36 16:30:26 112 processes: 11 running, 82 sleeping, 19 waiting CPU 0: 1.1% user, 0.0% nice, 20.3% system, 0.4% interrupt, 78.2% idle CPU 1: 0.0% user, 0.0% nice, 16.9% system, 0.0% interrupt, 83.1% idle CPU 2: 0.8% user, 0.0% nice, 13.9% system, 0.0% interrupt, 85.3% idle CPU 3: 0.4% user, 0.0% nice, 9.4% system, 0.0% interrupt, 90.2% idle CPU 4: 0.0% user, 0.0% nice, 12.8% system, 0.0% interrupt, 87.2% idle CPU 5: 0.0% user, 0.0% nice, 24.4% system, 0.0% interrupt, 75.6% idle CPU 6: 0.4% user, 0.0% nice, 16.5% system, 0.0% interrupt, 83.1% idle CPU 7: 0.0% user, 0.0% nice, 12.8% system, 0.4% interrupt, 86.8% idle Mem: 2154M Active, 145M Inact, 1243M Wired, 188K Cache, 1919M Buf, 20G Free Swap: 32G Total, 32G Free kvm_open: cannot open /proc/65556/mem PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 14 root 171 ki31 0K 16K CPU4 4 3593.9 94.78% [idle: cpu4] 11 root 171 ki31 0K 16K CPU7 7 3554.9 91.94% [idle: cpu7] 16 root 171 ki31 0K 16K RUN 2 3412.9 89.94% [idle: cpu2] 15 root 171 ki31 0K 16K CPU3 3 3534.7 86.96% [idle: cpu3] 13 root 171 ki31 0K 16K CPU5 5 3415.1 86.82% [idle: cpu5] 17 root 171 ki31 0K 16K RUN 1 3268.1 82.76% [idle: cpu1] 12 root 171 ki31 0K 16K CPU6 6 3427.9 80.18% [idle: cpu6] 18 root 171 ki31 0K 16K CPU0 0 3175.9 77.29% [idle: cpu0] 41 root -68 - 0K 16K CPU6 6 536.9H 17.63% [em1 taskq] 40 root -68 - 0K 16K CPU5 5 533.9H 17.19% [em0 taskq] 43 root -68 - 0K 16K - 0 345.5H 11.96% [em3 taskq] 42 root -68 - 0K 16K - 7 393.6H 10.30% [em2 taskq] 3 root -68 - 0K 16K sleep 4 277.0H 8.01% [ng_queue1] 5 root -68 - 0K 16K sleep 2 276.6H 7.96% [ng_queue3] 4 root -68 - 0K 16K sleep 2 276.5H 7.91% [ng_queue2] 9 root -68 - 0K 16K sleep 4 276.0H 7.86% [ng_queue7] 8 root -68 - 0K 16K sleep 1 276.5H 7.71% [ng_queue6] 2 root -68 - 0K 16K sleep 3 276.4H 7.67% [ng_queue0] 44691 root 48 0 2290M 2253M select 0 267.4H 7.47% /usr/local/sbin/mpd5 -p /var/run/mp 6 root -68 - 0K 16K sleep 3 276.1H 7.42% [ng_queue4] 7 root -68 - 0K 16K sleep 4 276.4H 7.18% [ng_queue5] 37290 root 45 0 8912K 4836K select 2 157.2H 2.00% /sbin/routed -s бокс бсд 9.0, адаптер igb last pid: 65984; load averages: 0.82, 0.98, 1.05 up 0+23:27:06 16:32:40 170 processes: 12 running, 118 sleeping, 40 waiting CPU 0: 0.0% user, 0.0% nice, 4.3% system, 15.0% interrupt, 80.7% idle CPU 1: 0.0% user, 0.0% nice, 5.9% system, 10.6% interrupt, 83.5% idle CPU 2: 0.0% user, 0.0% nice, 9.1% system, 5.1% interrupt, 85.8% idle CPU 3: 0.0% user, 0.0% nice, 2.4% system, 4.3% interrupt, 93.3% idle CPU 4: 0.4% user, 0.0% nice, 11.4% system, 5.5% interrupt, 82.7% idle CPU 5: 0.4% user, 0.0% nice, 7.9% system, 5.9% interrupt, 85.8% idle CPU 6: 0.0% user, 0.0% nice, 6.7% system, 3.9% interrupt, 89.4% idle CPU 7: 0.0% user, 0.0% nice, 3.9% system, 5.9% interrupt, 90.2% idle Mem: 34M Active, 64M Inact, 874M Wired, 180K Cache, 1434M Buf, 22G Free Swap: 4068M Total, 4068M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 128K CPU7 7 22.4H 98.68% [idle{idle: cpu7}] 11 root 155 ki31 0K 128K CPU2 2 22.0H 95.75% [idle{idle: cpu2}] 11 root 155 ki31 0K 128K CPU6 6 22.0H 95.51% [idle{idle: cpu6}] 11 root 155 ki31 0K 128K CPU1 1 21.3H 92.24% [idle{idle: cpu1}] 11 root 155 ki31 0K 128K CPU3 3 22.4H 91.50% [idle{idle: cpu3}] 11 root 155 ki31 0K 128K CPU4 4 21.1H 91.26% [idle{idle: cpu4}] 11 root 155 ki31 0K 128K RUN 5 21.4H 90.62% [idle{idle: cpu5}] 11 root 155 ki31 0K 128K CPU0 0 21.1H 88.09% [idle{idle: cpu0}] 13 root -16 - 0K 128K CPU0 1 43:44 4.93% [ng_queue{ng_queue2}] 12 root -92 - 0K 656K CPU1 1 33:04 4.59% [intr{irq265: igb1:que}] 13 root -16 - 0K 128K sleep 6 43:49 4.54% [ng_queue{ng_queue6}] 13 root -16 - 0K 128K sleep 0 43:48 4.54% [ng_queue{ng_queue3}] 13 root -16 - 0K 128K CPU2 1 43:48 4.49% [ng_queue{ng_queue0}] 13 root -16 - 0K 128K sleep 2 43:38 4.49% [ng_queue{ng_queue7}] 13 root -16 - 0K 128K sleep 4 43:41 4.35% [ng_queue{ng_queue5}] 13 root -16 - 0K 128K sleep 4 43:38 4.35% [ng_queue{ng_queue4}] 13 root -16 - 0K 128K sleep 6 43:38 4.30% [ng_queue{ng_queue1}] 12 root -92 - 0K 656K WAIT 0 33:12 3.52% [intr{irq272: igb1:que}] 12 root -92 - 0K 656K WAIT 4 21:59 3.27% [intr{irq260: igb0:que}] 1061 root 22 0 16264K 6084K select 0 38:03 3.17% /sbin/routed -s 12 root -92 - 0K 656K WAIT 2 20:49 2.69% [intr{irq258: igb0:que}] 12 root -92 - 0K 656K WAIT 5 23:22 2.64% [intr{irq261: igb0:que}] 12 root -92 - 0K 656K WAIT 3 13:05 2.64% [intr{irq267: igb1:que}] 12 root -92 - 0K 656K WAIT 3 23:21 2.59% [intr{irq259: igb0:que}] 12 root -92 - 0K 656K WAIT 0 21:31 2.59% [intr{irq256: igb0:que}] 1271 root 21 0 153M 37932K select 0 26:33 2.34% /usr/local/sbin/mpd5 -p /var/run/mpd5.pid -b{mpd5} 12 root -92 - 0K 656K WAIT 7 26:01 2.25% [intr{irq263: igb0:que}] 12 root -92 - 0K 656K WAIT 1 22:59 2.25% [intr{irq257: igb0:que}] 12 root -92 - 0K 656K WAIT 6 22:21 2.10% [intr{irq262: igb0:que}] 12 root -92 - 0K 656K WAIT 7 15:43 1.81% [intr{irq271: igb1:que}] 12 root -92 - 0K 656K WAIT 6 11:59 1.17% [intr{irq270: igb1:que}] 12 root -92 - 0K 656K WAIT 2 13:56 1.12% [intr{irq266: igb1:que}] 12 root -92 - 0K 656K WAIT 4 20:15 0.78% [intr{irq268: igb1:que}] 12 root -92 - 0K 656K WAIT 5 11:08 0.68% [intr{irq269: igb1:que}] 12 root -60 - 0K 656K WAIT 0 45:38 0.29% [intr{swi4: clock}] в последнем случае система больше занята обработкой прерываний, чем в первом случае nas26# sysctl dev.igb | fgrep -v ": 0" dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PCI7.PCX5 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x1516 subvendor=0x8086 subdevice=0x12b2 class=0x020000 dev.igb.0.%parent: pci31 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 65536003 dev.igb.0.rx_processing_limit: 4096 dev.igb.0.link_irq: 2 dev.igb.0.device_control: 1087373889 dev.igb.0.rx_control: 67141634 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147484159 dev.igb.0.fc_high_water: 33168 dev.igb.0.fc_low_water: 33152 dev.igb.0.queue0.tx_packets: 124420620 dev.igb.0.queue0.rx_packets: 122507255 dev.igb.0.queue0.rx_bytes: 106101932341 dev.igb.0.queue1.tx_packets: 115121642 dev.igb.0.queue1.rx_packets: 132079168 dev.igb.0.queue1.rx_bytes: 111344666742 dev.igb.0.queue2.tx_packets: 106614820 dev.igb.0.queue2.rx_packets: 122987702 dev.igb.0.queue2.rx_bytes: 106799550469 dev.igb.0.queue3.tx_packets: 174423989 dev.igb.0.queue3.rx_packets: 132981679 dev.igb.0.queue3.rx_bytes: 110916768973 dev.igb.0.queue4.tx_packets: 87802818 dev.igb.0.queue4.rx_packets: 120621051 dev.igb.0.queue4.rx_bytes: 104658465808 dev.igb.0.queue5.tx_packets: 92895132 dev.igb.0.queue5.rx_packets: 131391007 dev.igb.0.queue5.rx_bytes: 116388519040 dev.igb.0.queue6.tx_packets: 125848001 dev.igb.0.queue6.rx_packets: 121984029 dev.igb.0.queue6.rx_bytes: 107319987520 dev.igb.0.queue7.tx_packets: 304455062 dev.igb.0.queue7.rx_packets: 128304420 dev.igb.0.queue7.rx_bytes: 102505053766 dev.igb.0.mac_stats.total_pkts_recvd: 1012907120 dev.igb.0.mac_stats.good_pkts_recvd: 1012833970 dev.igb.0.mac_stats.bcast_pkts_recvd: 14631 dev.igb.0.mac_stats.mcast_pkts_recvd: 244998 dev.igb.0.mac_stats.rx_frames_64: 106660995 dev.igb.0.mac_stats.rx_frames_65_127: 231956538 dev.igb.0.mac_stats.rx_frames_128_255: 46966607 dev.igb.0.mac_stats.rx_frames_256_511: 30098155 dev.igb.0.mac_stats.rx_frames_512_1023: 30063489 dev.igb.0.mac_stats.rx_frames_1024_1522: 567088185 dev.igb.0.mac_stats.good_octets_recvd: 870067820654 dev.igb.0.mac_stats.good_octets_txd: 635696148967 dev.igb.0.mac_stats.total_pkts_txd: 1131558521 dev.igb.0.mac_stats.good_pkts_txd: 1131558520 dev.igb.0.mac_stats.bcast_pkts_txd: 208 dev.igb.0.mac_stats.mcast_pkts_txd: 32780 dev.igb.0.mac_stats.tx_frames_64: 266920035 dev.igb.0.mac_stats.tx_frames_65_127: 380571311 dev.igb.0.mac_stats.tx_frames_128_255: 46040511 dev.igb.0.mac_stats.tx_frames_256_511: 19880836 dev.igb.0.mac_stats.tx_frames_512_1023: 23355850 dev.igb.0.mac_stats.tx_frames_1024_1522: 394789979 dev.igb.0.interrupts.asserts: 1608551452 dev.igb.0.interrupts.rx_pkt_timer: 1012823317 dev.igb.0.interrupts.tx_queue_empty: 1131566432 dev.igb.0.interrupts.tx_queue_min_thresh: 2157076637 dev.igb.0.host.rx_pkt: 10655 dev.igb.0.host.tx_good_pkt: 15826 dev.igb.0.host.rx_good_bytes: 870086387150 dev.igb.0.host.tx_good_bytes: 635708566011 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 handle=\_SB_.PCI0.PCI7.PCX6 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x1516 subvendor=0x8086 subdevice=0x12b2 class=0x020000 dev.igb.1.%parent: pci31 dev.igb.1.nvm: -1 dev.igb.1.enable_aim: 1 dev.igb.1.fc: 65536003 dev.igb.1.rx_processing_limit: 4096 dev.igb.1.link_irq: 2 dev.igb.1.device_control: 1087373889 dev.igb.1.rx_control: 67141634 dev.igb.1.interrupt_mask: 4 dev.igb.1.extended_int_mask: 2147484159 dev.igb.1.fc_high_water: 33168 dev.igb.1.fc_low_water: 33152 dev.igb.1.queue0.tx_packets: 1077911367 dev.igb.1.queue0.rx_packets: 106986708 dev.igb.1.queue0.rx_bytes: 53761453485 dev.igb.1.queue1.tx_packets: 2697548 dev.igb.1.queue1.rx_packets: 123186385 dev.igb.1.queue1.rx_bytes: 59332077566 dev.igb.1.queue2.tx_packets: 3370235 dev.igb.1.queue2.rx_packets: 115556949 dev.igb.1.queue2.rx_bytes: 55878695611 dev.igb.1.queue3.tx_packets: 3842923 dev.igb.1.queue3.rx_packets: 180356373 dev.igb.1.queue3.rx_bytes: 77250752960 dev.igb.1.queue4.tx_packets: 3268534 dev.igb.1.queue4.rx_packets: 90609612 dev.igb.1.queue4.rx_bytes: 38652511103 dev.igb.1.queue5.tx_packets: 4198756 dev.igb.1.queue5.rx_packets: 104505013 dev.igb.1.queue5.rx_bytes: 52970780779 dev.igb.1.queue6.tx_packets: 5966022 dev.igb.1.queue6.rx_packets: 135890397 dev.igb.1.queue6.rx_bytes: 72549986822 dev.igb.1.queue7.tx_packets: 2871477 dev.igb.1.queue7.rx_packets: 310599547 dev.igb.1.queue7.rx_bytes: 247439421220 dev.igb.1.mac_stats.total_pkts_recvd: 1167764381 dev.igb.1.mac_stats.good_pkts_recvd: 1167690923 dev.igb.1.mac_stats.bcast_pkts_recvd: 36943 dev.igb.1.mac_stats.rx_frames_64: 32221383 dev.igb.1.mac_stats.rx_frames_65_127: 495963502 dev.igb.1.mac_stats.rx_frames_128_255: 208958433 dev.igb.1.mac_stats.rx_frames_256_511: 19762584 dev.igb.1.mac_stats.rx_frames_512_1023: 24195974 dev.igb.1.mac_stats.rx_frames_1024_1522: 386589047 dev.igb.1.mac_stats.good_octets_recvd: 662506409124 dev.igb.1.mac_stats.good_octets_txd: 886950769052 dev.igb.1.mac_stats.total_pkts_txd: 1105017574 dev.igb.1.mac_stats.good_pkts_txd: 1105017573 dev.igb.1.mac_stats.bcast_pkts_txd: 560 dev.igb.1.mac_stats.tx_frames_64: 43639074 dev.igb.1.mac_stats.tx_frames_65_127: 284026611 dev.igb.1.mac_stats.tx_frames_128_255: 165826535 dev.igb.1.mac_stats.tx_frames_256_511: 31325414 dev.igb.1.mac_stats.tx_frames_512_1023: 27681418 dev.igb.1.mac_stats.tx_frames_1024_1522: 552518522 dev.igb.1.mac_stats.tso_txd: 776174 dev.igb.1.interrupts.asserts: 1529614217 dev.igb.1.interrupts.rx_pkt_timer: 1167680684 dev.igb.1.interrupts.tx_queue_empty: 1105005295 dev.igb.1.interrupts.tx_queue_min_thresh: 23470617 dev.igb.1.host.rx_pkt: 10241 dev.igb.1.host.tx_good_pkt: 12279 dev.igb.1.host.rx_good_bytes: 662506418380 dev.igb.1.host.tx_good_bytes: 886950769052 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 7 марта, 2012 · Жалоба больше похоже на lattency. мож драйвер igb "больше полезной работы делает" :) было бы правильно сравнить 7.3 с igb, или 9.0 с em Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 7 марта, 2012 · Жалоба Попробуйте sysctl dev.igb.0.enable_aim=0. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 7 марта, 2012 · Жалоба больше похоже на lattency. мож драйвер igb "больше полезной работы делает" :) было бы правильно сравнить 7.3 с igb, или 9.0 с em ну ломать насы нет возможности, а вот то что система больше уходит в прерывания, имхо, не зер гуд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 7 марта, 2012 · Жалоба а чего ломать - поставить 7.3 на тот где igb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 7 марта, 2012 · Жалоба Попробуйте sysctl dev.igb.0.enable_aim=0. Спасибо, будем пробовать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 8 марта, 2012 · Жалоба isr одинаково настроен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 9 апреля, 2012 (изменено) · Жалоба <kan5300@nas1>uptime 2:39PM up 12 days, 2:09, 2 users, load averages: 0.52, 0.59, 0.64 Кажется проблема обнаружена! Регулярные ребуты (1.5 ребута за неделю в среднем) происходили изза GENERIC-ядра с активированным по-умолчанию IPv6. Закомментили поддержку всяких ненужных устройств и "#options INET6". Как видно из аптайма, в среду будет две недели непрерывной работы. PS: спасибо Hawk128 за совет Изменено 9 апреля, 2012 пользователем kaN5300 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 9 апреля, 2012 · Жалоба Пожалуйста. Но это не решение проблемы. Все равно придется ipv6 поднимать. Есть подозрения сейчас на проблемы опускания интерфейса нетграфом и взаимодействия с quaggой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 9 апреля, 2012 · Жалоба Пожалуйста. Но это не решение проблемы. Все равно придется ipv6 поднимать. Есть подозрения сейчас на проблемы опускания интерфейса нетграфом и взаимодействия с quaggой. У нас кстати тоже квагга используется (0.99.20_3) но она строго к igb0 привязана для общения с L3 коммутаторами и принятия от них маршрутов в локалку. Про нетграф она знать ничего не должна. К моменту ввода ipv6 мы планируем вобще отказаться от ната и туннелирования. Сервера доступа к тому времени переквалифицируются во что-то другое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 9 апреля, 2012 · Жалоба quagga знает и лезет в каждый ngx... Это и проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dadv Опубликовано 11 апреля, 2012 · Жалоба Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 11 апреля, 2012 · Жалоба Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'. Я вот как раз после оптимизации ipfw начал применять одно правило с ng* в продакшене. Посмотрим как себя поведет система. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 12 апреля, 2012 · Жалоба Короче, приобрели новый сервак на ксеончике четырехядерном. Поставили 9.0 amd64, обновили до STABLE, убрав из ядра лишние устройства и IPV6. В ipfw сейчас всего три основных правила, через которые льется львиная доля трафика. Таблица с 3k записей используется только в одном правиле из этих трех и с указаничем "in recv igb1". В час пик было 630 туннелей. При этом средний load average 1.0, максимальный 2.0. Максимальный kpps: 38. Начинаем отсчет бесперебойной работы. Аналогичные работы по удалению из ядра ipv6 и ненужных девайсов проведены еще на двух серверах, один из которых успел уже проработать более двух недель без перезагрузок. Всего у нас щас 3 наса под 9.0-STABLE (из них один на i386) и два на 7.4-STABLE i386 с ядром GENERIC. 7.Х работает уже давно и периодичность зависания в среднем реже одного раза в месяц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 апреля, 2012 · Жалоба периодичность зависания в среднем реже одного раза в месяц И вам абоны за такой "сервис" мозг не вынесли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 12 апреля, 2012 · Жалоба периодичность зависания в среднем реже одного раза в месяц И вам абоны за такой "сервис" мозг не вынесли? У абонентов происходит обычный реконнект к свободному соседнему серверу. Они ничего не замечают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 апреля, 2012 · Жалоба У абонентов происходит обычный реконнект к свободному соседнему серверу. Угу, когда сессия отвалится по тайм-ауту. Или у вас нет ограничений на кол-во сессий с учетки? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 12 апреля, 2012 · Жалоба У абонентов происходит обычный реконнект к свободному соседнему серверу. Угу, когда сессия отвалится по тайм-ауту. Или у вас нет ограничений на кол-во сессий с учетки? Тайм-аут <= 60 секунд. Ей богу. Один дисконнект у 1/5 авторизованных абонентов раз в 45 суток не повод для паники. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...