olloviel

нагуглил эту тему, спросил что делают другие :) было net.isr.dispatch=direct, изменил на deferred. Если не ошибаюсь, раньше были проблемы со стабильностью при deffered, посмотрю что будет сейчас. Нагрузка развалилась на ядра, перешла из system в interrupt: Если я правильно понимаю, вместо прямой обработки в контексте прерывания пакеты буферизируются и дальше через софтовые прерывая обрабатываются ядрами? Не могу найти описание работы net.isr.dispatch=hybrid, можете в двух словах объяснить?

@orca аналогичная проблема, на двухпроцессорном сервере не могу загрузить второй проц, kernel{if_io_tqg} работают только для первого: last pid: 10429; load averages: 2.02, 2.48, 2.61 up 181+05:36:00 10:46:22 404 threads: 26 running, 311 sleeping, 1 zombie, 66 waiting CPU 0: 0.0% user, 0.0% nice, 12.5% system, 0.0% interrupt, 87.5% idle CPU 1: 0.4% user, 0.0% nice, 24.3% system, 0.0% interrupt, 75.3% idle CPU 2: 0.0% user, 0.0% nice, 19.6% system, 0.0% interrupt, 80.4% idle CPU 3: 0.0% user, 0.0% nice, 20.4% system, 0.0% interrupt, 79.6% idle CPU 4: 0.0% user, 0.0% nice, 18.0% system, 0.0% interrupt, 82.0% idle CPU 5: 0.0% user, 0.0% nice, 27.5% system, 0.0% interrupt, 72.5% idle CPU 6: 0.0% user, 0.0% nice, 30.2% system, 0.0% interrupt, 69.8% idle CPU 7: 0.0% user, 0.0% nice, 23.1% system, 0.0% interrupt, 76.9% idle CPU 8: 0.0% user, 0.0% nice, 22.0% system, 0.0% interrupt, 78.0% idle CPU 9: 0.0% user, 0.0% nice, 20.8% system, 0.0% interrupt, 79.2% idle CPU 10: 0.0% user, 0.0% nice, 1.2% system, 0.0% interrupt, 98.8% idle CPU 11: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle CPU 12: 1.5% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.1% idle CPU 13: 3.1% user, 0.0% nice, 0.4% system, 0.0% interrupt, 96.5% idle CPU 14: 4.2% user, 0.0% nice, 0.4% system, 0.0% interrupt, 95.4% idle CPU 15: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle CPU 16: 0.8% user, 0.0% nice, 0.4% system, 0.0% interrupt, 98.8% idle CPU 17: 6.5% user, 0.0% nice, 1.5% system, 0.0% interrupt, 92.0% idle CPU 18: 0.8% user, 0.0% nice, 1.5% system, 0.0% interrupt, 97.7% idle CPU 19: 0.4% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.2% idle Mem: 221M Active, 3733M Inact, 138M Laundry, 2621M Wired, 1234M Buf, 9618M Free Swap: 4096M Total, 181M Used, 3915M Free, 4% Inuse PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0B 320K CPU11 11 4261.6 100.00% idle{idle: cpu11} 11 root 155 ki31 0B 320K CPU18 18 4251.6 100.00% idle{idle: cpu18} 11 root 155 ki31 0B 320K CPU10 10 4263.3 99.65% idle{idle: cpu10} 11 root 155 ki31 0B 320K CPU12 12 4260.0 99.44% idle{idle: cpu12} 11 root 155 ki31 0B 320K RUN 15 4256.1 99.40% idle{idle: cpu15} 11 root 155 ki31 0B 320K CPU16 16 4254.6 99.38% idle{idle: cpu16} 11 root 155 ki31 0B 320K CPU19 19 4250.3 99.03% idle{idle: cpu19} 11 root 155 ki31 0B 320K CPU14 14 4257.5 97.64% idle{idle: cpu14} 11 root 155 ki31 0B 320K RUN 13 4258.8 96.23% idle{idle: cpu13} 11 root 155 ki31 0B 320K CPU17 17 4253.5 94.76% idle{idle: cpu17} 11 root 155 ki31 0B 320K CPU0 0 3347.7 86.14% idle{idle: cpu0} 11 root 155 ki31 0B 320K CPU2 2 3391.5 83.33% idle{idle: cpu2} 11 root 155 ki31 0B 320K CPU3 3 3336.5 82.17% idle{idle: cpu3} 11 root 155 ki31 0B 320K CPU4 4 3335.6 79.46% idle{idle: cpu4} 11 root 155 ki31 0B 320K CPU8 8 3285.0 78.04% idle{idle: cpu8} 11 root 155 ki31 0B 320K RUN 1 3363.6 77.26% idle{idle: cpu1} 11 root 155 ki31 0B 320K RUN 7 3389.8 76.11% idle{idle: cpu7} 11 root 155 ki31 0B 320K RUN 9 3234.2 75.77% idle{idle: cpu9} 11 root 155 ki31 0B 320K CPU5 5 3199.1 71.87% idle{idle: cpu5} 11 root 155 ki31 0B 320K RUN 6 3335.0 69.75% idle{idle: cpu6} 0 root -76 - 0B 1168K CPU6 6 1001.0 30.14% kernel{if_io_tqg_6} 0 root -76 - 0B 1168K CPU5 5 1127.2 27.65% kernel{if_io_tqg_5} 0 root -76 - 0B 1168K - 9 1102.2 24.06% kernel{if_io_tqg_9} 0 root -76 - 0B 1168K - 7 945.5H 23.72% kernel{if_io_tqg_7} 0 root -76 - 0B 1168K - 1 972.1H 22.58% kernel{if_io_tqg_1} 0 root -76 - 0B 1168K - 8 1050.8 21.81% kernel{if_io_tqg_8} 0 root -76 - 0B 1168K - 4 1000.1 20.33% kernel{if_io_tqg_4} 0 root -76 - 0B 1168K - 3 999.7H 17.60% kernel{if_io_tqg_3} 0 root -76 - 0B 1168K CPU2 2 944.1H 16.46% kernel{if_io_tqg_2} 0 root -76 - 0B 1168K - 0 987.5H 13.63% kernel{if_io_tqg_0} 95679 djbdns 22 0 1041M 958M select 14 42.1H 6.57% dnscache 10364 postgres 21 0 173M 83M select 17 0:01 6.41% postgres 10382 postgres 21 0 173M 87M select 17 0:01 4.76% postgres Что обидно, в гугле про эту проблему буквально две темы на форумах. Такое ощущение, что никто трафик на freebsd не роутит/натит. Была надежда на freebsd 13, но судя по Вашему посту надо думать что-то еще. Не появилось у Вас новой информации? Как сами будете решать проблему?

Подскажите, как с консоли сделать привязку mac/ip acl к порту? Мануал читал, но там только пример для web интерфейса. Кому не жалко, поделитесь примером блокировки 67 порта на клиентских портах. Заранее спасибо!

только L2, acl нет, загрузка проца dgs - 2-3%

насколько я знаю, под freebsd такого пакета нет, приведу те же данные только из netstat # netstat -I igb1 -d -h Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop igb1 1500 <Link#2> 00:16:31:fa:02:2f 80M 14 0 101M 0 0 0 igb1 1500 192.168.3.0 192.168.3.1 0 - - 0 - - - как видно ошибок ничтожно мало, дропов нет Наверно таки тему надо называть "тюнинг igb freebsd", хотя я так и не понимаю, виноват сервер или DGS. Как проверить кто же крайний? Оба устройства предпочитают помалкивать о виновных.. Обновление драйвера ничего не поменяла, симптомы те же, резкий провал пакетов на интерфейсе: # netstat -I igb1 -w1 -h input (igb1) output packets errs idrops bytes packets errs bytes colls 22K 0 0 8.8M 30K 0 33M 0 21K 0 0 8.0M 29K 0 33M 0 21K 0 0 7.5M 29K 0 33M 0 21K 0 0 7.2M 28K 0 32M 0 15K 0 0 5.2M 24K 0 27M 0 7.7K 0 0 2.3M 15K 0 16M 0 5.2K 0 0 1.7M 10K 0 11M 0 9.9K 0 0 2.7M 15K 0 15M 0 13K 0 0 4.9M 17K 0 18M 0 21K 0 0 7.8M 29K 0 32M 0 22K 0 0 8.0M 30K 0 34M 0 22K 0 0 8.8M 28K 0 30M 0 23K 0 0 9.0M 29K 0 33M 0 Может кто подскажет еще какие могут быть варианты диагностики как сервера так и свича?

Итак, появилась возможность написать еще одно сообщение :) flow-control выключены и на сетевухе сервера и на свиче. За сегодняшний день проблема локализовалась: потери появляются "периодами", скажем за час есть 5 минут, когда валят потери, потом опять тишина и т.д. Во время когда идут потери, трафик через остальные порты DGS бегает нормально. Т.е. конкретно потери между сервером и DGS. В один из периодов успел снять статистику по сетевке на сервере: так все работало: # netstat -I igb1 -h -w1 input (igb1) output packets errs idrops bytes packets errs bytes colls 19K 0 0 6.4M 25K 0 30M 0 18K 0 0 6.1M 24K 0 28M 0 20K 0 0 5.8M 27K 0 32M 0 и тут началось: packets errs idrops bytes packets errs bytes colls 1.8K 0 0 252K 2.9K 0 2.5M 0 1.9K 0 0 453K 2.5K 0 1.8M 0 1.7K 0 0 348K 2.5K 0 1.9M 0 Как видно, на сетевушке резко упало количество пакетов как на вход, так и на выход В общем у меня сложилось впечатление, что DGS с дропами вообще непричем. Как пользователи уснут покрепче, обновлю драйвер на igb. Сейчас стоит igb1: <Intel® PRO/1000 Network Connection version - 2.3.1> на сайте интела нашелся 2.3.7.

Убрал линки 100Мбит, к сожалению эффекта ноль, пинги теряются как и раньше. Со стороны сервера # netstat -I igb1 -h Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll igb1 1500 <Link#2> 00:16:31:fa:02:2f 125M 1 0 166M 0 0 igb1 1500 192.168.3.0 192.168.3.1 0 - - 0 - - Просто ставит в тупик абсолютная случайность потерь, то трафика 250-300Мбит - потерь нет, то каждый третий теряется в течении 5 минут, потом отпускает...

в процессе поисков меняли много, но все в сторону упрощения :) sh fdb Total Entries: 275 sh arpentry Total Entries: 5 Нет, счетчик растет периодами, сейчас за всю ночь увеличился где-то на сотню. Когда начинаются потери растет сотнями в секунду. не подскажите как вычислить/проверить? Оба да, спасибо за идею, сегодня уберу 100Мбит, посмотрю что будет

Подскажите пожалуйста, кто сталкивался, на свиче DGS-3627 растут счетчики Dropped Packets. Куда копать? Проблема не гипотетическая, теряются пинги по локалке Command: show error ports 5 Port number : 5 RX Frames TX Frames --------- --------- CRC Error 0 Excessive Deferral 0 Undersize 0 CRC Error 0 Oversize 0 Late Collision 0 Fragment 0 Excessive Collision 0 Jabber 0 Single Collision 0 Drop Pkts 71066 Collision 0 Symbol Error 0 Buffer Full Drop 0 ACL Drop 0 Multicast Drop 0 VLAN Ingress Drop 0 Command: show cpu access_profile CPU Interface Filtering State: Disabled CPU Interface Access Profile Table is empty Command: show utilization ports Port TX/sec RX/sec Util Port TX/sec RX/sec Util ----- ---------- ---------- ---- ----- ---------- ---------- ---- 1 0 0 0 22 911 4026 24 2 0 0 0 23 3029 2500 14 3 4648 3371 3 24 0 0 0 4 0 0 0 25 0 0 0 5 17068 22690 14 26 0 0 0 6 14409 9790 8 27 0 0 0 7 0 0 0 8 0 0 0 9 0 0 0 10 840 805 1 11 75 24 1 12 556 692 1 13 68 7 1 14 63 0 1 15 814 778 1 16 1271 1212 1 17 0 0 0 18 0 0 0 19 0 0 0 20 0 0 0 21 6198 3419 4 Command: show utilization cpu CPU Utilization ------------------------------------------------------------------------------- Five seconds - 3 % One minute - 2 % Five minutes - 2 %