_longhorn_

alex_admin Консольный шнур подходит от Cisco. Сбросить не сложно, подключаетесь консолью к нему и во время загрузки будет написано что нажать, конкретно что надо нажимать уже не помню. На район его можно спокойно ставить, должен вытянуть.

terrible Попробуйте отключить LRO.

Никто не мешает откатиться на 6.9.14 под 8-STABLE.К слову, в 7-STABLE уже тоже дрова 7.0.5.

Lynx10 Сказали что действительно есть такая проблема, отправили на баржу радиограмму, кетайцы приняли, пишут... :-) Только что-то долго...

Около полугода назад купили 3610, работает нормально за исключением lacp, Dlink признал проблему, однако решения пока нету. В остальном все работает хорошо, даже BGP :-).

nevzorofff Если 320 маршрутов тогда даже не знаю... Не много это, должно и с OSPF нормально работать.

nevzorofff Какое количество маршрутов /32 приходит на бордер? Попробуйте перейти на втором брасе с OSPF на iBGP.

Dyr Не собираются из-за этого Как вариант можно попробовать откатить изменения.

AntonS Pps действительно много, на соседней машине нету lagg, так там pps раза в полтора меньше. Вчера снова начались проблемы, пробовал net.isr.direct=0 с патченым netisr, дал net.isr.maxthreads=8 и ng_queue сразу вернулся в норму. Не пойму никак в чем дело..

Что у Вас за тарифы такие :-) ? У меня счас 800/690 Мбит/с, чуть больше 1Мппс, 1350 человек. Пока рабтает, но вчера как только перевалило за 1400 история повторилась. Не могу понять в чем дело.

Вчера вкрутил ET-шку, объединил её в lagg и завел на неё внешку, PT-шку тоже объединил и пустил внутрь сети. Впринципе это не помогло, только отсрочило час "Х". Нагрузка перед конвульсиями была такая: netstat -h 1 948K 0 596M 915K 0 583M 0 951K 0 604M 916K 0 592M 0 926K 0 591M 894K 0 578M 0 947K 0 598M 911K 0 584M 0 907K 0 598M 870K 0 580M 0 944K 0 601M 910K 0 588M 0 input (Total) output packets errs bytes packets errs bytes colls 943K 0 597M 908K 0 586M 0 970K 0 612M 934K 0 603M 0 951K 0 602M 919K 0 596M 0 948K 0 602M 916K 0 594M 0 944K 0 605M 911K 0 593M 0 1.0M 0 672M 996K 0 666M 0 1.0M 0 644M 971K 0 640M 0 988K 0 629M 954K 0 626M 0 990K 0 633M 955K 0 630M 0 976K 0 632M 940K 0 628M 0 967K 0 632M 933K 0 626M 0 981K 0 634M 950K 0 635M 0 977K 0 632M 943K 0 630M 0 Это около 1300 человек онлайна, в тор-е при этом свободно было процентов по 60 каждого ядра. Затем, когда людей стало больше 1400, ситуация повторилась, тоесть снова ng_queue забрал 100% одного ядра. Пробовать без ng_car будет напряжно, все тарифы прийдется переделывать, сейчас все скорости высылаются радиусом. Попробую сперва без яндексов, если не даст результата - тогда буду откатывать все это на dummynet...

Всем добрый день. Недавно столкнулся с интересной проблемой: есть комп Core i7 930, 6Gb DDR3-1600, Intel PRO/1000 PT Dual Port, на нем стоит FreeBSD 7.3-STABLE, mpd5.5, дрова yandex последние, терминация PPPoE, шейп ng_car. Иногда один из процессов ng_queue выжирает до 100% одного из CPU, нагрузка при этом следующая: top -SP PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 15 root 1 171 ki31 0K 16K CPU3 3 71:13 95.56% idle: cpu3 13 root 1 171 ki31 0K 16K RUN 5 69:06 92.87% idle: cpu5 17 root 1 171 ki31 0K 16K CPU1 1 67:13 81.69% idle: cpu1 11 root 1 171 ki31 0K 16K RUN 7 63:41 77.39% idle: cpu7 12 root 1 171 ki31 0K 16K CPU6 6 58:56 72.17% idle: cpu6 14 root 1 171 ki31 0K 16K RUN 4 54:10 65.77% idle: cpu4 16 root 1 171 ki31 0K 16K CPU2 2 50:51 61.28% idle: cpu2 18 root 1 171 ki31 0K 16K CPU0 0 50:15 59.57% idle: cpu0 10946 root 1 43 - 0K 16K WAIT 1 19:18 27.49% em1_rx_kthread_2 45 root 1 43 - 0K 16K CPU7 7 19:31 27.29% em1_rx_kthread_1 44 root 1 43 - 0K 16K CPU4 4 19:29 26.86% em1_rx_kthread_0 10947 root 1 43 - 0K 16K WAIT 6 19:17 26.76% em1_rx_kthread_3 40 root 1 43 - 0K 16K WAIT 0 18:59 25.20% em0_rx_kthread_0 6982 root 1 43 - 0K 16K WAIT 2 18:44 23.97% em0_rx_kthread_2 6983 root 1 43 - 0K 16K WAIT 2 18:45 23.88% em0_rx_kthread_3 41 root 1 43 - 0K 16K WAIT 0 19:01 23.49% em0_rx_kthread_1 20 root 1 -32 - 0K 16K WAIT 3 12:06 6.40% swi4: clock sio 86600 root 1 96 0 79876K 35588K select 0 1:45 0.98% mpd5 43 root 1 -68 - 0K 16K WAIT 0 2:11 0.29% em1_txcleaner 4 root 1 -68 - 0K 16K sleep 5 1:32 0.00% ng_queue2 7 root 1 -68 - 0K 16K sleep 2 1:22 0.00% ng_queue5 39 root 1 -68 - 0K 16K WAIT 7 1:03 0.00% em0_txcleaner 2 root 1 -68 - 0K 16K sleep 0 1:01 0.00% ng_queue0 3 root 1 -68 - 0K 16K sleep 0 0:52 0.00% ng_queue1 9 root 1 -68 - 0K 16K sleep 0 0:36 0.00% ng_queue7 6 root 1 -68 - 0K 16K sleep 5 0:33 0.00% ng_queue4 8 root 1 -68 - 0K 16K sleep 6 0:18 0.00% ng_queue6 5 root 1 -68 - 0K 16K sleep 6 0:12 0.00% ng_queue3 # ifconfig |grep ng|wc -l 1243 netstat -h 1 packets errs bytes packets errs bytes colls 579K 0 343M 679K 0 443M 0 592K 0 352M 697K 0 455M 0 585K 0 348M 687K 0 454M 0 584K 0 355M 684K 0 454M 0 597K 0 355M 698K 0 464M 0 587K 0 352M 687K 0 457M 0 587K 0 352M 691K 0 460M 0 570K 0 341M 675K 0 447M 0 # vmstat -z|grep tG NetGraph items: 72, 65565, 104, 796, 166617025, 0 NetGraph data items: 72, 32805, 1, 10484, 1394356793, 0 при этом 870 Мбит/с трафика. Когда один из ng_queue выростает до 100% начинается потеря пакетов, в это время в vmstat -z: NetGraph items: 72, 65565, 104, 796, 166617025, 0 NetGraph data items: 72, 32805, 9574, 4286, 1394356793, 0 Временно помогло dev.em.0.rx_int_delay=900, dev.em.0.rx_abs_int_delay=2000... При этом на сетевухах все хорошо: em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 725605214 em1: Good Packets Xmtd = 688318866 em1: TSO Contexts Xmtd = 0 em1: TSO Contexts Failed = 0 Если кто-то сталкивался с подобным буду признателен за совет, заранее спасибо.

X-RaY™ А что в коредампе?

X-RaY™ Не уверен, но возможно причина в net.inet.ip.fastforwarding.

AntonS Какая система, что в sysctl.conf? На 7.3-STABLE и 8.0-STABLE без проблем заводится с hw.igb.rxd=4096 hw.igb.txd=4096. Если дрова 1.8.4 то надо отключать LRO через ifconfig.

mikevlz У кого-то простаивают, у кого-то работают :-)

sdy_moscow Даже ни разу не улыбнуло, не смешно.

Lynx10 Если речь о PPPoE, то PT Dual/Quad Port, если бордер - можно ET.

Lynx10 Я бы посмотрел в сторону Core i7, Intel PRO/1000 PT Dual Port, FreeBSD, MPD. При хорошем раскладе отправили бы на пенсию свой теремок квадов с риалтеками и поставили бы два нормальных i7 c PT-шками.

Приятно слышать :) Большое спасибо, ждем с нетерпением!

wawa После недавнего обновления em и igb дров в RELENG_8 не собирается ядро с яндексами. Планируется ли обновленная версия Ваших драйверов?

Вы наверно не понимаете главного. При поллинге вся сетевая подсистема в единый момент времени обрабатывается ОДНИМ ядром. Я уже не знаю как Вам объяснить столь очевидные вещи. Насчет яндексов у Вас вообще, как я понимаю, свой взгляд на Мир. У всех они работают прекрасно, а Вам не угодили. Если у других все хорошо стоит поискать проблему у себя.

Он работает со всеми ядрами, но не параллельно, а по очереди.

Я смотрю, и вижу, что у вас вся сетевая подсистема работает на одном ядре. А что видите Вы?

Какая разница как включается поллинг? Хоть через сисктл, хоть через ифконфиг, всеравно он использует только одно ядро. Если планируете нагружать этот комп, я бы посоветовал задуматься уже сейчас, чтобы не кусать локти потом.