orca
-
Публикации
200 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем orca
-
-
1 час назад, DDR сказал:
попробуйте добавить в /boot/loader.conf
dev.ix.0.iflib.override_nrxqs=8 dev.ix.0.iflib.override_ntxqs=8 dev.ix.1.iflib.override_nrxqs=8 dev.ix.1.iflib.override_ntxqs=8
Это все пробовал.
Оно меняет количество очередей сетевой карты, но эти очереди потом распределяются по if_io_tqg_ количество которых равно количеству ядер в системе. При двух процессорах работают только if_io_tqg_ которые привязаны к первому процессору.
В рассылку не писал. Честно говоря никогда туда не писал только читал иногда. -
Здравствуйте, пишу сюда чтоб не плодить темы. Недавно обновился до FreeBSD 13, но началось все еще с 12 как появился iflib.
Поведение на разных серверах, аналогичное.
CPU 2 x CPU E5-2670
Сетевая карта ix, драйвер стандартный который идет с системой
Как я понял при загрузке создаются потоки для каждого ядра процессора.procstat -at | grep if_io
0 100019 kernel if_io_tqg_0 -1 24 sleep -
0 100020 kernel if_io_tqg_1 -1 24 sleep -
0 100021 kernel if_io_tqg_2 -1 24 sleep -
0 100022 kernel if_io_tqg_3 -1 24 sleep -
0 100023 kernel if_io_tqg_4 -1 24 sleep -
0 100024 kernel if_io_tqg_5 -1 24 sleep -
0 100025 kernel if_io_tqg_6 -1 24 sleep -
0 100026 kernel if_io_tqg_7 -1 24 sleep -
0 100027 kernel if_io_tqg_8 -1 24 sleep -
0 100028 kernel if_io_tqg_9 -1 24 sleep -
0 100029 kernel if_io_tqg_10 -1 24 sleep -
0 100030 kernel if_io_tqg_11 -1 24 sleep -
0 100031 kernel if_io_tqg_12 -1 24 sleep -
0 100032 kernel if_io_tqg_13 -1 24 sleep -
0 100033 kernel if_io_tqg_14 -1 24 sleep -
0 100034 kernel if_io_tqg_15 -1 24 sleep -
Когда даю нагрузку на сеть, судя по top работают только первые 8 потоков, которые работают с первым процессором. Получается второй процессор вообще не используется.
Пробовал разные комбинации тюнинга sysctl не получается с iflib задействовать второй процессор.
Помогает только поставить драйвер ix из портов. Тогда появляется по 8 потоков на каждый порт сетевой карты, которые можно распределить по ядрам всех процессоров.
Но так не всегда удобно, если в сервере более 16 ядер то лишние не используются, а если менее 16 то попадает по несколько потоков на одно ядро.Думал может в FreeBSD 13 что то изменилось, но нет.
-
В 27.12.2019 в 15:50, z18 сказал:
Спасибо помогло. Еще добавил это:
https://reviews.freebsd.org/D22848 -
Опубликовано · Изменено пользователем orca · Жалоба на ответ
8 минут назад, Ivan_83 сказал:А у вас коммутатор перед фрёй вообще умеет igmp snooping?
Оно там как сейчас в нём настроено?
Да snooping умеет, если в ipfw на сервере режу igmp, мультикаст пропадает.
В tcpdump вижу igmp reportы.
Утилита ifmcstat показывает кучу групп. В описании утилиты написано: "The ifmcstat command dumps multicast group information from the kernel."
Как убрать эти группы из ядра и почему они сами не убираются, неясно. -
35 минут назад, vlad11 сказал:
Вы плохо себе представляете, как работает мультикаст влан.
Это не мультикаст влан, это обычный влан с мультикастом.
17 минут назад, Ivan_83 сказал:А почему вы думаете что мультикаст трафик не должен попадать на фрю?
Поставьте msd_lite, там хотя бы понятно точно есть кто то на канале или нет, и вроде в явном виде шлётся запрос на покидание группы.
И оно под нагрузки по более двух калек приспособлено.
Кадры могут пропадать только если у вас входящий линк забит полностью.
Дальше я бы смотрел дропы на интерфейсах и сетевом стёке.
Но это всё после выпиливания udpxy.
С дропами я разобрался. Вопрос не в этом.
Я разбирался почему на сервер приходит мультикаста в два раза больше чем уходит юникаста на клиентов.Непонятно почему фря продолжает слать igmp reportы после того как канал смотреть перестали.
msd_lite попробую, может действительно поможет. -
Есть сервер FreeBSD 12.1-RELEASE-p1 GENERIC amd64, один физический интерфейс, в нем два vlan.
Один влан смотрит в Интернет, другой принимает мультикаст. Запущен udpxy.
Клиент из интернет подключается к udpxy, сервер шлет igmp запрос в vlan с мультиксат, в ответ получает мультикаст поток и передает его по http клиенту, сервер периодически шлет igmp report.
Все хорошо, все работает.
Начались жалобы на пропадания кадров.
Заметил очень большую разницу в объемах трафика между вланами.
Стал разбираться. Оказалось после того как клиент от канала отключился, либо переключил на другой канал, сервер все равно продолжает слать igmp reportы, и получает мультикаст. На сервер идут все потоки которые когда либо смотрели, не зависимо от того смотрят их сейчас или нет.
Даже если полностью убить udpxy, мультикаст продолжает идти на сервер.
Если запретить в фаерволе igmp, через пару минут мультикаст останавливается (на свиче igmp snooping работает правильно), после удаления правил все возвращается.
Утилита ifmcstat показывает все группы на которые подписан сервер. Как их оттуда убрать я не нашел.
Пробовал на стороне источника мультикаст переключать igmp v2 и v3, на сервере igmp тоже переключается вслед за источником, но группы он не покидает.
ОС обновил с 11.2, там она вела себя аналогично. -
Здравствуйте. Никто не смог подружить pppoe mpd5 с FreeBSD 10x ?
Сейчас у меня FreeBSD 9.3 + MPD 5.7_3, в пике 800-850 pppoe сессий. Работает относительно стабильно. Где то год назад, когда обновлял железо пытался запустить на десятке. Тогда сервер, после непродолжительной работы уходил в ступор и реагировал только на ресет, что конкретно писал в лог уже не вспомню.
-
Я откатился на 9,2 проблема решилась. Видимо не все гладко у десятки с нетграфом.
-
А кто нибудь решил первоначальную проблему с FreeBSD 10 и mpd 5.7 ? Или только откатывать на 9.2?
У меня после обновления до 10.0 тоже стали появляться такие зависания с umtxn. Никак не могу вычислить зависимость. Может зависнуть в час пик когда много сессий и наоборот рано утром когда нагрузка минимальна.
-
Удивительно, вчера поставил ваши значения sysctl уже сутки прошли, полет нормлаьный. Буду наблюдать дальше.
-
Вот vmstat -z сейчас, как только проявится проблема выложу vmstat в момент проблемы.
vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 91, 11, 91, 0 UMA Zones: 320, 0, 91, 5, 91, 0 UMA Slabs: 568, 0, 2884, 7, 68964, 0 UMA RCntSlabs: 568, 0, 13113, 5, 75138, 0 UMA Hash: 256, 0, 0, 0, 3, 0 16 Bucket: 152, 0, 15, 110, 157, 0 32 Bucket: 280, 0, 72, 110, 352, 2 64 Bucket: 536, 0, 113, 27, 640, 12 128 Bucket: 1048, 0, 3274, 8, 56099548, 84810 VM OBJECT: 216, 0, 60394, 23576, 324540970, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 150660, 52, 320, 124643, 0 MAP ENTRY: 120, 0, 1963, 185773, 3364430189, 0 DP fakepg: 120, 0, 0, 0, 0, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 273, 6, 273, 0 16: 16, 0, 2942, 922, 1615660809, 0 32: 32, 0, 4034, 2228, 311547309, 0 64: 64, 0, 7830, 12498, 284182348, 0 128: 128, 0, 7719, 7448, 20336634, 0 256: 256, 0, 12708, 25347, 299483174170, 0 512: 512, 0, 1976, 9119, 1138660582, 0 1024: 1024, 0, 96, 472, 4627799, 0 2048: 2048, 0, 97, 733, 8038099, 0 4096: 4096, 0, 410, 802, 13880322, 0 Files: 80, 0, 155, 2095, 436712459, 0 TURNSTILE: 136, 0, 970, 70, 970, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1120, 0, 59, 730, 13553375, 0 THREAD: 1112, 0, 865, 104, 1116, 0 SLEEPQUEUE: 80, 0, 970, 74, 970, 0 VMSPACE: 392, 0, 37, 733, 13553349, 0 cpuset: 72, 0, 11, 139, 11, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 8286, 576, 584479950323, 335140 mbuf: 256, 0, 2, 2086, 27383308637, 0 mbuf_cluster: 2048, 25600, 8862, 16738, 7031947819, 658150 mbuf_jumbo_page: 4096, 12800, 0, 313, 120836, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 NetGraph items: 72, 4118, 0, 0, 0, 0 NetGraph data items: 72, 522, 0, 0, 0, 0 g_bio: 232, 0, 0, 12640, 31502129, 0 ttyinq: 160, 0, 150, 186, 1215, 0 ttyoutq: 256, 0, 80, 100, 648, 0 ata_request: 320, 0, 0, 36, 20, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 93692, 14156, 28310950, 0 VNODEPOLL: 112, 0, 0, 66, 1, 0 S VFS Cache: 108, 0, 104006, 14662, 26684396, 0 L VFS Cache: 328, 0, 379, 25505, 2097288, 0 NAMEI: 1024, 0, 0, 796, 362732275, 0 DIRHASH: 1024, 0, 1609, 287, 23231, 0 NFSMOUNT: 624, 0, 0, 0, 0, 0 NFSNODE: 688, 0, 0, 0, 0, 0 pipe: 728, 0, 2, 368, 12559613, 0 ksiginfo: 112, 0, 774, 777, 231712, 0 itimer: 344, 0, 0, 99, 5355, 0 KNOTE: 128, 0, 21, 2183, 1522203985, 0 socket: 680, 25602, 65, 2005, 314696049, 0 unpcb: 240, 25600, 34, 350, 551700, 0 ipq: 56, 819, 0, 378, 203694, 0 udp_inpcb: 336, 25608, 12, 2012, 305972843, 0 udpcb: 16, 25704, 12, 2172, 305972843, 0 tcp_inpcb: 336, 25608, 16, 699, 1861363, 0 tcpcb: 880, 25600, 15, 181, 1861363, 0 tcptw: 72, 5150, 1, 999, 1745493, 0 syncache: 144, 15366, 0, 286, 1698491, 0 hostcache: 136, 15372, 2, 138, 664, 0 tcpreass: 40, 1680, 0, 420, 7047, 0 sackhole: 32, 0, 0, 505, 408, 0 sctp_ep: 1272, 25602, 0, 0, 0, 0 sctp_asoc: 2240, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 144, 5, 0 sctp_raddr: 616, 80004, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 96, 400026, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 336, 25608, 3, 393, 6310120, 0 rtentry: 200, 0, 56, 191, 874, 0 IPFW dynamic rule: 120, 0, 0, 0, 0, 0 selfd: 56, 0, 964, 1052, 385319447, 0 SWAPMETA: 288, 116519, 162, 5207, 698275, 0 ip4flow: 56, 99351, 877, 18338, 229198098, 0 ip6flow: 80, 99360, 0, 0, 0, 0 Mountpoints: 752, 0, 5, 10, 5, 0 FFS inode: 168, 0, 93654, 18766, 28310328, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 93654, 18201, 28310327, 0
-
Здравствуйте, есть такая проблема: Система FreeBSD 8.2-RELEASE-p3, ядро GENERIC amd64. Иногда, не зависимо от нагрузки на роутер, перестаёт идти трафик через один VLAN. В этом влане у меня абоненты. В логах пусто.
Кроме перезагрузки помогает только выключение и включение самого интерфейса ifconfig igb1 down, ifconfig igb1 up.
Никакой зависимости от времени суток, количества пакетов, количества абонентов в сети, нагрузки на процессор я не нашел.
Что это может быть и как с этим бороться?
-
Отчего он мрёт? Процессор не справляется? Сетевые карты нормальные? Какие значения bps/pps?
Во время атак на УльтраКомп у меня на ДНС-сервер шёл флуд по 40-50 мегабит в секунду, но ничего не мёрло.
Да процессор не справляется, не расчитывали на такой скаче нагрузки. Сейчас другое железо подбираем.
-
У меня такая же беда. С начала ДНСы стали спотыкаться, поменял bind на unbound, теперь бордер мрет. Что с этой заразой делать, неясно.
-
Подойдет ли Extreme BD 12802, на бордер для небольшой сети на 2К-3К пользователей.
-
Опубликовано · Изменено пользователем orca · Жалоба на ответ
Кстати подобная проблема стала появляться и у меня на hp proliant dl360 g7
Система FreeBSD 8.1 AMD64
Сетевая внешняя двухпортовая intel (igb)
С прошлой ночи начались проблемы с vlan.
Без каких либо видимых причин некоторые вланы перестают работать. В таблице arp этих вланов все хосты incomplete кроме самого себя.
Помогает удалить и потом создать влан, либо перезагрузить весь сервер.
За последние сутки проблема появлялась 3 раза, в логах всё девственно чисто.
З.Ы.
Вряд ли проблема в железе так как сервера 2 одинаковых. 2 раза глюкнуло на одном и 1 раз на другом.
-
Присоединюсь к вопросу.
Сейчас стоит:
core2duo E8400 2Gb DDR2 сетевая Intel PRO/1000 двухголовая
система FreeBSD 7.3 AMD64, nat ng_nat, шейпер IPFW + DUMMYNET, netflow ng_netflow отправляет на другую машину
Выше 140 килопакетов, начинаются потери пакетов, процессор загружен под завязку.
Что посоветуете?
Апгрейд на core2quad
Апгрейд на corei5 DDR3
Апгрейд на FreeBSD 8.0
Тюнинг sysctl
Поставить рядом ещё одну такую же машину и распределить нагрузку
Ещё хотелось бы узнать какой максимум можно из данной конфигурации выжать.
-
2 ems_viking
С органайзерами все более менее понятно. Надо покупать и ставить.
Теперь вопросы:
В правом верхнем углу на фторой фотографии. Кроссы с оптикой были уже с органайзерами или их тоже отдельно можно купить?
По какому алогоритму оставляется пустое место между юнитами? Чтоб не перегревалось, или кабеля некуда спрятать, или из расчета на будущее, или так гламурнее выглядит? А может все вместе?
На второй фотке справа поцентрумного витой пары. Красивее и удобнее уложить никак? У меня похожая история, уже пообжимал пачкорды нужной длины чтоб небыло колец, стало лучше, но не все нравится. Неудобно добираться до нужного пачкорда, часто цепляются соседние.
-
Может кто-нибудь написать инструкцию как правильно заполнять стойки? Как укладывать оптические пачкорды, как витую пару, куда девать провода питания, как продумать расположение самого обрудования, что делать если у одного оборудования разъемы спереди, а у другого сзади. Что нужно сразу покупать кроме самой стойки. На картинках у вас все красиво выглядит, а в реальной жизни чем больше оборудования, тем больше похоже на ваши ужастики :(
-
есть образ куда слать?
-
Вот этот роутер много чего умеет http://wl500g.info/forumdisplay.php?f=86 а с нестандартными прошивками ещё больше :)
-
Но вот тут http://www.dlink.ru/products/prodview.php?type=19&id=499 написано:
"Функции вызова
Перенаправление вызова (Call Transfer)
Удержание вызова (Call Hold)
Ожидание вызова (Call Waiting)
Отображение идентификатора вызывающего абонента (Callre ID display) "
Вопрос в том как этим пользоваться?
-
Нигде немогу найти информацию как перевести вызов на этом шлюзе. В описании на сайте написано что он это умеет, но как непонятно.
-
У Freebsd есть терминалы которые можно подключать через com порт. В
документации это всё хорошо описано и скорее всего работает. У меня ситуация
такова: есть несколько серверов корпуса у них rackmount видеокарту туда
воткнуть не получается. Решил я для мониторинга (если вдруг по сети нет
возможности зайти) использовать терминалы т.е. подключился с ноутбука через
com порт к серверу и работаешь. Всё хорошо только вот на материнских платах
нету com портов.
Вопрос к сообществу, возможно ли тоже самое сделать через usb?
Я так понимаю кроме софта ещё и кабель специальный для этого спаять придется
потому что нульмодемных usb я не видел.
Не работает quagga в freebsd 13.0
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Жалоба на ответ
Тоже пришлось с quagga на frr переходить.
Когда quagga на 13.0 добавляет в систему маршруты в dmesg вот такое сыпется:
mask sin_len too small
frr вроде работает нормально