olloviel Опубликовано 21 июля, 2021 · Жалоба @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, но судя по Вашему посту надо думать что-то еще. Не появилось у Вас новой информации? Как сами будете решать проблему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 21 июля, 2021 · Жалоба 1 час назад, olloviel сказал: Такое ощущение, что никто трафик на freebsd не роутит/натит. Не знаю насчет "никто", но я от этого ушел совсем почти лет 10 тому назад. Особенно задалбливал NAT. Сервер стабильно уходил в полный ступор раз, а то и два в месяц. Плюнул (слюной, как рекомендовал тов. Бендер :-) ) и отправил эти "процедуры" на CentOS. С тех пор про этот страшный сон не вспоминаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 июля, 2021 · Жалоба 17 часов назад, olloviel сказал: на двухпроцессорном сервере не могу загрузить второй проц, kernel{if_io_tqg} работают только для первого А делали то что? net.isr крутили? В рассылке спрашивали? Маны читали? 16 часов назад, AlKov сказал: Не знаю насчет "никто", но я от этого ушел совсем почти лет 10 тому назад. Особенно задалбливал NAT. Сервер стабильно уходил в полный ступор раз, а то и два в месяц. Плюнул (слюной, как рекомендовал тов. Бендер :-) ) и отправил эти "процедуры" на CentOS. Анонимный страдалец :) Нет чтобы в багтрекер и рассылку долбить, так лучше сидеть и ждать чуда, а потом свалить туда где уже другие всё сделали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 22 июля, 2021 · Жалоба 4 часа назад, Ivan_83 сказал: Нет чтобы в багтрекер и рассылку долбить, так лучше сидеть и ждать чуда, а потом свалить туда где уже другие всё сделали. Что поделать, остались еще чудаки, предпочитающие "ехать" вместо "шашечек". ;-) P.S. Ну а для гурманов немного перефразирую А. Иванова Ты пиши, пиши, пиши, Сочиняй весь век, Потому что пародистпрограммист - Тоже человек. Он не хочет затянуть Туже поясок. Для него твои стихи - Хлебушка кусок. Ты пиши и мой призыв Не сочти за лесть, Потому что пародистпрограммист Тоже хочет есть! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
olloviel Опубликовано 22 июля, 2021 · Жалоба 5 hours ago, Ivan_83 said: А делали то что? нагуглил эту тему, спросил что делают другие :) On 9/21/2020 at 11:57 PM, Ivan_83 said: В сисцтл (меняется без ребута): net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. было net.isr.dispatch=direct, изменил на deferred. Если не ошибаюсь, раньше были проблемы со стабильностью при deffered, посмотрю что будет сейчас. Нагрузка развалилась на ядра, перешла из system в interrupt: Spoiler last pid: 75402; load averages: 2.33, 2.78, 2.67 up 182+04:18:27 09:28:53 401 threads: 25 running, 312 sleeping, 1 zombie, 63 waiting CPU 0: 1.2% user, 0.0% nice, 3.1% system, 4.3% interrupt, 91.3% idle CPU 1: 0.8% user, 0.0% nice, 5.9% system, 8.3% interrupt, 85.0% idle CPU 2: 0.0% user, 0.0% nice, 7.1% system, 3.9% interrupt, 89.0% idle CPU 3: 0.4% user, 0.0% nice, 7.9% system, 6.7% interrupt, 85.0% idle CPU 4: 1.6% user, 0.0% nice, 7.5% system, 7.9% interrupt, 83.1% idle CPU 5: 0.8% user, 0.0% nice, 7.9% system, 5.5% interrupt, 85.8% idle CPU 6: 0.8% user, 0.0% nice, 9.4% system, 4.3% interrupt, 85.4% idle CPU 7: 0.8% user, 0.0% nice, 4.7% system, 10.6% interrupt, 83.9% idle CPU 8: 0.0% user, 0.0% nice, 2.8% system, 7.5% interrupt, 89.8% idle CPU 9: 0.0% user, 0.0% nice, 7.1% system, 9.1% interrupt, 83.9% idle CPU 10: 0.0% user, 0.0% nice, 0.4% system, 7.9% interrupt, 91.7% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 9.8% interrupt, 90.2% idle CPU 12: 0.8% user, 0.0% nice, 0.8% system, 5.9% interrupt, 92.5% idle CPU 13: 0.4% user, 0.0% nice, 0.0% system, 8.3% interrupt, 91.3% idle CPU 14: 0.0% user, 0.0% nice, 0.4% system, 8.7% interrupt, 90.9% idle CPU 15: 0.4% user, 0.0% nice, 0.4% system, 11.0% interrupt, 88.2% idle CPU 16: 0.4% user, 0.0% nice, 0.8% system, 22.8% interrupt, 76.0% idle CPU 17: 0.8% user, 0.0% nice, 0.0% system, 5.1% interrupt, 94.1% idle CPU 18: 0.8% user, 0.0% nice, 1.6% system, 10.6% interrupt, 87.0% idle CPU 19: 0.4% user, 0.0% nice, 0.4% system, 12.2% interrupt, 87.0% idle Mem: 218M Active, 4232M Inact, 138M Laundry, 2810M Wired, 1423M Buf, 9595M 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 CPU12 12 4282.2 93.28% idle{idle: cpu12} 11 root 155 ki31 0B 320K CPU17 17 4275.6 92.29% idle{idle: cpu17} 11 root 155 ki31 0B 320K CPU10 10 4285.4 91.24% idle{idle: cpu10} 11 root 155 ki31 0B 320K CPU11 11 4283.8 91.00% idle{idle: cpu11} 11 root 155 ki31 0B 320K CPU13 13 4280.9 90.14% idle{idle: cpu13} 11 root 155 ki31 0B 320K CPU14 14 4279.7 89.84% idle{idle: cpu14} 11 root 155 ki31 0B 320K CPU0 0 3366.4 89.63% idle{idle: cpu0} 11 root 155 ki31 0B 320K CPU2 2 3409.8 89.04% idle{idle: cpu2} 11 root 155 ki31 0B 320K CPU15 15 4278.3 88.99% idle{idle: cpu15} 11 root 155 ki31 0B 320K CPU18 18 4273.7 88.27% idle{idle: cpu18} 11 root 155 ki31 0B 320K CPU7 7 3407.7 87.33% idle{idle: cpu7} 11 root 155 ki31 0B 320K CPU3 3 3354.8 87.27% idle{idle: cpu3} 11 root 155 ki31 0B 320K CPU8 8 3303.3 86.99% idle{idle: cpu8} 11 root 155 ki31 0B 320K CPU1 1 3381.9 86.91% idle{idle: cpu1} 11 root 155 ki31 0B 320K CPU5 5 3215.4 86.59% idle{idle: cpu5} 11 root 155 ki31 0B 320K CPU6 6 3352.4 86.52% idle{idle: cpu6} 11 root 155 ki31 0B 320K CPU4 4 3353.4 84.22% idle{idle: cpu4} 11 root 155 ki31 0B 320K CPU19 19 4272.4 83.74% idle{idle: cpu19} 11 root 155 ki31 0B 320K CPU9 9 3251.8 82.59% idle{idle: cpu9} 11 root 155 ki31 0B 320K CPU16 16 4276.7 75.28% idle{idle: cpu16} 12 root -72 - 0B 1072K CPU16 16 7:28 24.12% intr{swi1: netisr 16} 12 root -72 - 0B 1072K CPU19 19 5:43 15.38% intr{swi1: netisr 19} 12 root -72 - 0B 1072K WAIT 9 5:26 12.43% intr{swi1: netisr 9} 12 root -72 - 0B 1072K WAIT 18 4:41 10.72% intr{swi1: netisr 18} 12 root -72 - 0B 1072K WAIT 15 4:59 9.96% intr{swi1: netisr 15} 12 root -72 - 0B 1072K WAIT 4 3:08 9.79% intr{swi1: netisr 4} 12 root -72 - 0B 1072K WAIT 14 3:41 9.10% intr{swi1: netisr 14} 95679 djbdns 24 0 1041M 958M select 16 43.6H 8.86% dnscache 12 root -72 - 0B 1072K WAIT 13 3:47 8.83% intr{swi1: netisr 13} 12 root -72 - 0B 1072K WAIT 11 5:47 8.39% intr{swi1: netisr 11} 12 root -72 - 0B 1072K WAIT 1 3:24 7.82% intr{swi1: netisr 1} 12 root -72 - 0B 1072K WAIT 10 4:16 7.72% intr{swi1: netisr 10} 12 root -72 - 0B 1072K WAIT 7 3:10 7.28% intr{swi1: netisr 7} 12 root -72 - 0B 1072K WAIT 6 2:25 6.86% intr{swi1: netisr 6} 12 root -72 - 0B 1072K WAIT 8 2:56 6.79% intr{swi1: netisr 8} 0 root -76 - 0B 1168K - 3 1004.0 6.59% kernel{if_io_tqg_3} Если я правильно понимаю, вместо прямой обработки в контексте прерывания пакеты буферизируются и дальше через софтовые прерывая обрабатываются ядрами? Не могу найти описание работы net.isr.dispatch=hybrid, можете в двух словах объяснить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 23 июля, 2021 · Жалоба В 22.07.2021 в 09:15, AlKov сказал: Что поделать, остались еще чудаки, предпочитающие "ехать" вместо "шашечек". ;-) Это не инженерный подход где человек получает деньги за решение чужих проблем, это консьюмерский подход где человек платит за то чтобы ему всё сделали. Сейчас у вас ожидание что всё должно работать без приложения усилий. Вы видимо сами этого не осознали ещё а только на пути к осознанию, дальше вам предстоит уйти с линукса на готовые железки и венду, ну а потом нанять человека чтобы он эти готовые железки настраивал и перейти на ипад. Всего два шага осталось и такая мелочь как источник денег найти :) В 22.07.2021 в 09:42, olloviel сказал: Нагрузка развалилась на ядра, перешла из system в interrupt Это не прерывания. В 22.07.2021 в 09:42, olloviel сказал: Если я правильно понимаю, вместо прямой обработки в контексте прерывания пакеты буферизируются и дальше через софтовые прерывая обрабатываются ядрами? Не совсем. Директ это когда пакеты обрабатываются прямо в контексте прерывания. Благодаря всяким msi-x оно аппаратно размазывается на столько ядер сколько может железка или как то ещё запрогано. Можно поискать крутилки драйвера или iflib, вдруг там есть количество msi-x прерываний. Диспатч - это когда прерывание спихивает все пакеты в очередь ISR подсистемы и возвращается к обслуживанию своей железки. А ISR там уже внутри пакеты размазывает по обработчикам. Минус тут на мой взгляд только один и для меня он вообще не существенный - увеличивается время на обработку пакета, на какие то мизерные доли секунды, но для геймеров и высокочастотных трейдеров это может быть критическим недостатком. Раньше ещё были отдельно нетграф потоки обработчики, но как я понял или в 12 или 13 их выкинули и переделали на ISR, чтобы не плодить одинаковые сущности. Гибрид - не знаю, вернее забыл. Попробуйте найти в рассылках или документации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 23 июля, 2021 · Жалоба hybrid режим влияет на ровно один момент: если пакет прилетел с того же ядра, на котором уже ожидает обработчик протокола - пакет отправляется обработчику напрямую, иначе улетает в общую очередь, как в deferred Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 26 июля, 2021 · Жалоба В 24.07.2021 в 00:03, Ivan_83 сказал: Это не инженерный подход.. Это есть нормальный подход инженера-технолога, внедряющего в производство разработки инженера-конструктора. Все остальное, уж извините, ваши досужие домыслы.. Соглашусь - немного подправив - с .. В 24.07.2021 в 00:03, Ivan_83 сказал: дальше вамвсем, использующим *nix сетевые решения, предстоит уйти с линукса на готовые железки и венду В "линуксах" эта тенденция, IMHO, тоже уже очень жирно просматривается.. Для себя лично надеюсь всех этих прелестей не застать. P.S. Предлагаю закончить дискуссию в этом направлении, т.к. она совсем не в тему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
WideAreaNetwork Опубликовано 17 января, 2022 (изменено) · Жалоба есть проблема с брасом, проц по каким-то причинам грузится в полку начинаются расти пинги, а потом идут потери FreeBSD 12.2-RELEASE-p12 GENERIC amd64 было p7 обновил безопасность пока, не могу понять причины такого поведения, в логах messagess и dmesg.today пусто как в момент проблемы так и до нее за несколько часов и после, подумал может ДДОС но тогда трафик должен резко вырасти, но он наоборот падает до проблемы никакого тюнинга в loader.conf и sysctl.conf не было, внес некоторые изменения но проблема все равно один раз вчера появилась, оно как-то рандомно, то ночью в 3 часа, то утром часов в 10, то вечером в любой время, пока-что после обновления безопасности не было такого, но не факт что не повториться loader.conf geom_mirror_load="YES" pf_load="YES" ipfw_load="YES" ipdivert_load="YES" dummynet_load="YES" autoboot_delay=2 loader_logo="beastie" ##### tuning ##### hw.ix.unsupported_sfp="1" # 0 hw.ix.flow_control=0 # 3 net.link.ifqmaxlen="16384" # (default 50) net.isr.defaultqlimit="4096" # (default 256) kern.ipc.nmbclusters="5242880" # 1010028 kern.ipc.nmbjumbop="2621440" # 505013 net.inet.tcp.syncache.hashsize="1024" # 512 net.inet.tcp.syncache.bucketlimit="100" # 30 net.isr.maxqlimit="1000000" # 10240 dev.ix.0.iflib.core_offset=1 # 0 dev.ix.0.iflib.override_nrxqs=7 # 0 dev.ix.0.iflib.override_ntxqs=7 # 0 hw.em.rx_process_limit="-1" sysctl.conf # $FreeBSD: releng/12.2/sbin/sysctl/sysctl.conf 337624 2018-08-11 13:28:03Z brd $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. net.inet.ip.dummynet.expire=0 #1 net.inet.ip.dummynet.hash_size=2048 #64 up to 65535 net.inet.ip.dummynet.pipe_slot_limit=1000 #100 up to 2048 or 4096 net.inet.ip.dummynet.io_fast=1 #0 uskoryaet sheyper ##### tuning pautina ###### net.inet.ip.intr_queue_maxlen=10240 #256 net.inet.ip.fw.dyn_max=65535 #16384 kern.ipc.maxsockbuf=16777216 # (wscale 9) # 2097152 net.inet.tcp.recvbuf_inc=65536 # (default 16384) net.inet.tcp.recvbuf_max=4194304 # (default 2097152) net.inet.tcp.recvspace=65536 # (default 65536) net.inet.tcp.sendbuf_inc=65536 # (default 8192) net.inet.tcp.sendbuf_max=4194304 # (default 2097152) net.inet.tcp.sendspace=65536 # (default 32768) net.inet.tcp.mssdflt=1460 # Option 1 (default 536) net.inet.tcp.minmss=536 # (default 216) net.inet.tcp.abc_l_var=44 # (default 2) if net.inet.tcp.mssdflt = 1460 net.inet.tcp.initcwnd_segments=44 # (default 10 for FreeBSD 11.2) if net.inet.tcp.mssdflt = 1460 net.inet.tcp.rfc6675_pipe=1 # (default 0) net.inet.tcp.syncache.rexmtlimit=0 # (default 3) net.inet.ip.maxfragpackets=0 # (default 31595) net.inet.ip.maxfragsperpacket=0 # (default 16) net.inet.tcp.syncookies=0 # (default 1) net.inet.tcp.isn_reseed_interval=4500 # (default 0, disabled) net.inet.tcp.tso=0 # (default 1) dev.ix.0.fc=0 # (default 3) dev.ix.0.iflib.rx_budget=65535 # (default 0, which is 16 frames) kern.random.fortuna.minpoolsize=128 # (default 64) kern.random.harvest.mask=65887 # (default 66047, FreeBSD 12 with Intel Secure Key RNG) net.inet.raw.maxdgram=16384 # (default 9216) net.inet.raw.recvspace=16384 # (default 9216) net.local.stream.sendspace=16384 # (default 8192) net.local.stream.recvspace=16384 # (default 8192) net.route.netisr_maxqlen=2048 # (default 256) hw.intr_storm_threshold=9000 # 1000 net.inet.icmp.reply_from_interface=1 net.bpf.optimize_writers=1 # bpf are write-only unless program explicitly specifies the read filter (default 0) net.inet.ip.check_interface=1 # verify packet arrives on correct interface (default 0) net.inet.ip.process_options=0 # ignore IP options in the incoming packets (default 1) net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving the system (default 0) net.inet.ip.redirect=0 # do not send IP redirects (default 1) net.inet.icmp.drop_redirect=1 # no redirected ICMP packets (default 0) net.inet.tcp.always_keepalive=0 # disable tcp keep alive detection for dead peers, keepalive can be spoofed (default 1) net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial connection (default 0) net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly (helps against DoS, but may cause false RST) (default 0) net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed icmp/udp floods (default 1) net.inet.tcp.msl=5000 # Maximum Segment Lifetime is the time a TCP segment can exist on the network and is # used to determine the TIME_WAIT interval, 2*MSL (default 30000 which is 60 seconds) net.inet.tcp.path_mtu_discovery=0 # disable MTU discovery since many hosts drop ICMP type 3 packets (default 1) net.inet.udp.blackhole=1 # drop udp packets destined for closed sockets (default 0) net.inet.tcp.blackhole=2 # drop tcp packets destined for closed ports (default 0) ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=c538b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,TXCSUM_IPV6> ether 0c:c4:7a:4f:40:3e media: Ethernet autoselect (10Gbase-Twinax <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> rc.conf ifconfig_ix0="up -rxcsum -txcsum -tso -lro" на скринах проседание трафика в момент проблемы 19:30-19:35, и длится не долго 1-2мин максмимум, чаще всего до минуты Изменено 17 января, 2022 пользователем WideAreaNetwork Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 января, 2022 · Жалоба Параметры net.inet.ip, net.inet.tcp, net.inet.udp - они для трафика который предназначен этому хосту и на транзинтный не влияют. (кроме димминета) В 17.01.2022 в 10:47, WideAreaNetwork сказал: pf_load="YES" ipfw_load="YES" ipdivert_load="YES" Оно точно надо? Диверт вообще проц жрёт при работе через него. В 17.01.2022 в 10:47, WideAreaNetwork сказал: kern.random.harvest.mask=65887 Тут надо уточнять чтобы прерывания с сетевухи не захватывались, и вообще для роутера энтропия в рандоме не очень то и нужна. А штормов/петель у вас в сети нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
WideAreaNetwork Опубликовано 19 января, 2022 · Жалоба В 19.01.2022 в 06:16, Ivan_83 сказал: Оно точно надо? Диверт вообще проц жрёт при работе через него. PF для ната IPFW им управляет биллинг, дает/закрывает доступ во внешнюю сеть IPDIVERT для заглушки В 19.01.2022 в 06:16, Ivan_83 сказал: А штормов/петель у вас в сети нет? не должно быть (ловили такое ранее там поведение совсем другое), но проверим, спс пока после обновлении безопасности и последующего ребута браса проблема не наблюдалась Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...