NiTr0 Опубликовано 25 ноября, 2016 · Жалоба NAT порядка 500 правил (режем серую сеть по /24 и натим во внешний адрес) т.е. каждый пакет пробегает в среднем 250 правил файрвола. отсюда и затыки... делайте нормальный нат в диапазон адресов и не мучьтесь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 25 ноября, 2016 · Жалоба Не каждый. Только первый из соединения. А что говорит pref top Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wiredom Опубликовано 26 ноября, 2016 · Жалоба Не каждый. Только первый из соединения. А что говорит pref top 5,51% [ixgbe] [k] ixgbe_poll 5,16% [ip_tables] [k] ipt_do_table 5,10% [kernel] [k] fib_table_lookup 4,41% [kernel] [k] __ticket_spin_lock 3,24% [ixgbe] [k] ixgbe_xmit_frame_ring 3,16% [nf_conntrack] [k] ____nf_conntrack_find 2,20% [kernel] [k] __copy_skb_header 2,13% [kernel] [k] nf_iterate 1,91% [kernel] [k] __netif_receive_skb 1,68% [kernel] [k] dev_queue_xmit 1,68% [kernel] [k] skb_release_head_state 1,35% [kernel] [k] check_leaf.isra.9 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 1 декабря, 2016 (изменено) · Жалоба 2 Wiredom net.netfilter.nf_conntrack_tcp_timeout_established = 90 жестокий вы человек :) а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать. конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть Изменено 1 декабря, 2016 пользователем nshut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wiredom Опубликовано 1 декабря, 2016 · Жалоба а вообще тоже склонен к правилам. если сделано для лучшего определения кто куда ходил. то временно нат в подсеть сделайте для оценки ситуации, а там думать. конечно пакет цепочку проходит один раз. Но в нат модуле проверка внешних айпи по возврату тоже 500 раз делается. Может ошибаюсь, но легче попробовать чем в исходники опять лезть Делал, какого то тотального результата не было. Условно говоря делал так: -t nat -A POSTROUTING -s x.x.x.x/16 -o eth0.8 -j SNAT --to-source xx.xx.xx.1-xx.xx.xx.254 (кстати наличие влана на высоконагруженном интерфейсе может как то влиять на нагрузку?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 1 декабря, 2016 · Жалоба кстати наличие влана на высоконагруженном интерфейсе может как то влиять на нагрузку? влан как и бондинг влияния практически не оказывает, при перестройке сети вечно то прихожу к вланам, то ухожу, разницы ноль. и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wiredom Опубликовано 1 декабря, 2016 (изменено) · Жалоба влан как и бондинг влияния практически не оказывает, при перестройке сети вечно то прихожу к вланам, то ухожу, разницы ноль. и еще, когда пишите загрузку, загрузка проца 65% понятие растяжимое, одно ядро 2%, другое 90. ну и плюс все от ппс зависит, трафик может быть ни о чем. графики выше показывают зависимость именно ппс. я бы увеличил tcp_establish время, ибо поиск в контреке это намного быстрее чем удаление, а удалив сессию открытую клиент ее переподымет заново, не знаю поможет ли, но чисто мое мнение. Графиков insert-delete никто (в отличии от бсдшников) не выкладывает, а зря. Нагрузка равномерно достаточно распределена между ядрами, поэтому не стал заострять на этом моменте, были бы перекосы я обязательно это упомянул бы. значение established я догнал до 600 Вот про insert-delete можно ткнуть носом что это и куда посмотреть... Кстати вот что забыл упомянуть совсем так это наличие quagga+bgp с кошками. На серере порядка 5к маршрутов (формата хост такой то шлюз до него такой то) кошек таких три. BGP нужно что бы роутер знал на каком брасе абонент и вернул трафик на нужный брас. Кол-во пакетов в секунду 280к 290к в пиках 300к (при этом загрузка до 65-70%) взлетает. Кстати, в сервере стоит второй проц еще. Но прерывания утащил все на один процессор, я думаю это влиять не может, но кто его знает (может влияет?) Изменено 1 декабря, 2016 пользователем Wiredom Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 1 декабря, 2016 · Жалоба в стейтфул фаерах есть понятие поиск, вставка, удаление сессии. Так доссы и ложат наты, отправляя много новых конектов. На линуксе не видел чтобы это анализировали, фрибсдшники всегда эти данные прикладывают, к примеру графики строить можно отсюда cat /proc/net/stat/nf_conntrack. Но не суть, раз никто этого не пишет, значит никто и не анализировал. Не помню в какой версии линукса выпилили роуте кэш, может это и есть проблема большого количества маршрутов. Я бы подумал как уйти от бгп. К примеру у наших натов два машрута, остальное делает маршрутизатор + немного pbr. конечно все зависит от индивидуальности конфигурации. Процессоры вещь вообще мутная. распайка влияет на производительность факт, но куча процессоров больше сделает чем куча в 2 раза меньше. Сколько не игрался показатели разные. Причем влияет сильно и мать. У меня 2 идентичных сервера lisg. Один лучше на 1 проце (на 2х дропает пакеты, хотя не загружен), второй на двух лучше первого, так что только тестинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 12 декабря, 2016 · Жалоба Кто может подсказать, softirq: Let ksoftirqd do its job из kernel 4.9 - есть ли от него польза софт роутеру? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[-Alt-] Опубликовано 13 декабря, 2016 · Жалоба У меня на пролианте 380g6 4.9 нормально не запустилось, вместо 4 ядер увидело одно, и выдало ошибку, что номера процов больше 16. Видел еще пару таких же сообщений о других моделях пролиантов. Вобще последние ядра очень странные, на 4.8 сломали nat --persistent, в 4.9 судя по всему поправили, но сломали еще что-то... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 30 апреля, 2017 · Жалоба к слову, никто не пробовал свежие камни от AMD в качестве софтроутеров/брасов/прочих трафикомолотилок? вроде как с латентностью кешей у них все намного лучше, чем у в меру старых интелов: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 апреля, 2017 · Жалоба Там улучшения видны только на фоне старых же атлонов, на фоне современных(и даже не очень) интелов - все плохо. Домашний древний i5-2500 с ddr3... + на скрине райзена - память работает на дикой частота 3600. На "штатных" 2133-2400 цифры будут совсем-совсем другие. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 30 апреля, 2017 · Жалоба ну штатно у ддр4 вообще-то 3200 не редкость, а 2133-2400 - это как ддр3 1066-1333 :) а есть возможность протестить этот i5 свежей версией аиды? как-то смущает разница в скорости чтения из кеша на порядок при близкой латентности... думается, алгоритм тестирования сменился немного... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 апреля, 2017 · Жалоба ну штатно у ддр4 вообще-то 3200 не редкость, а 2133-2400 - это как ддр3 1066-1333 :) Дык на скрине интела таки ddr4-2133 с дикими таймингами, некорректное сравнение. думается, алгоритм тестирования сменился немного Цифры изменились, таки разные версии Aida64 сравнивать в лоб нельзя. Но все равно латентность ниже чем у топового райзена. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 апреля, 2017 (изменено) · Жалоба Нашел скрин для kaby lake P.S. нашел и результаты райзена без экстремального разгона. Тут все грустно. Про роутеры на АМД и в этом поколении забываем :) Изменено 30 апреля, 2017 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Macil Опубликовано 1 мая, 2017 · Жалоба Про роутеры на АМД и в этом поколении забываем :)1. Райзен — это конструкция а-ля NUMA. Есть два блока (CCX) по четыре ядра, соединённых некой шиной с неизвестными характеристиками (известно что она работает на половинной частоте памяти).2. Кеш третьего уровня в одном CCX разделён, как минимум на четыре части (а судя по фоточкам, и на восемь). Соответственно, латентность варьируется (АМДшники этого и не скрывают). 3. L3 собран по модели victim cache: данные в L3 вытесняются из L2, соответственно в случае если нужно поместить данные в L2 из L3, место в L2 нужно освободить, вытеснив данные в L3. Минимальной латентности это не способствует. Исходя из вышеперечисленного, все эти тесты меряют среднюю температуру по больнице, и к реальности отношение имеют весьма слабое. Косяки архитектуры кешей компенсируются стоимостью, энергопотреблением и гигантскими объёмами. Но АМДшники — мерзкие свиньи. Они так и не удосужились выложить в открытый доступ руководство по оптимизации. Без него, все эти «тесты» и оценки ничем принципиально отличаются от сообщений агентства ОБС. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 2 мая, 2017 · Жалоба Macil Все эти особенности не мешают замерить латентность памяти - она в 1.5 раза выше чем у аналогичных интел'ов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
weirded Опубликовано 2 июня, 2017 (изменено) · Жалоба Я думаю это весьма уместная тема для небольшого самопиара: я недавно допилил набор тулз для мониторинга и тюнинга сетевого стека в Linux. Для самопальных софтроутеров - самое оно. Буду рад любому фидбэку :) Описание на русском: https://strizhechenko.github.io/2017/05/31/netutils-linux-1.2.11.html Исходники: https://github.com/strizhechenko/netutils-linux Изменено 2 июня, 2017 пользователем weirded Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 4 июня, 2017 · Жалоба Я думаю это весьма уместная тема для небольшого самопиара: я недавно допилил набор тулз для мониторинга и тюнинга сетевого стека в Linux. Для самопальных софтроутеров - самое оно. Буду рад любому фидбэку :) Описание на русском: https://strizhechenko.github.io/2017/05/31/netutils-linux-1.2.11.html Исходники: https://github.com/strizhechenko/netutils-linux [root@border-area2 netutils-linux]# network-top Traceback (most recent call last): File "/usr/bin/network-top", line 7, in <module> NetworkTop().run() File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/base_top.py", line 76, in run self.tick() File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 39, in tick self.current = self.parse() File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 30, in parse return dict((top_name, _top.parse()) for top_name, _top in self.tops.iteritems()) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/network_top.py", line 30, in <genexpr> return dict((top_name, _top.parse()) for top_name, _top in self.tops.iteritems()) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 65, in parse return dict((dev, self.__parse_dev__(dev)) for dev in self.options.devices) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 65, in <genexpr> return dict((dev, self.__parse_dev__(dev)) for dev in self.options.devices) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 90, in __parse_dev__ return dict((stat, self.__parse_dev_stat__(dev, stat)) for stat in self.stats) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 90, in <genexpr> return dict((stat, self.__parse_dev_stat__(dev, stat)) for stat in self.stats) File "/usr/lib/python2.6/site-packages/netutils_linux_monitoring/link_rate.py", line 95, in __parse_dev_stat__ with open('/sys/class/net/{0}/statistics/{1}'.format(dev, stat.filename)) as devfile: IOError: [Errno 20] Not a directory: '/sys/class/net/bonding_masters/statistics/rx_packets' В CentOs 6.8 bonding_masters - это файл. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 4 июня, 2017 · Жалоба Не надо трогать настройки сетивого стека! Он и так быстрый. Это вам не OpenBSD, где из сетивого стека надо в буквальном смысле все соки выжымать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
weirded Опубликовано 5 июня, 2017 · Жалоба Не надо трогать настройки сетивого стека! Он и так быстрый. Это вам не OpenBSD, где из сетивого стека надо в буквальном смысле все соки выжымать. Особенно когда он использует одно из 16 ядер с малой частотой всеми сетевыми картами! :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
weirded Опубликовано 5 июня, 2017 (изменено) · Жалоба В CentOs 6.8 bonding_masters - это файл. Исправлено: https://github.com/strizhechenko/netutils-linux/issues/68 Изменено 5 июня, 2017 пользователем weirded Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
neperpbl3 Опубликовано 20 июня, 2017 · Жалоба Здравствуйте, друзья! Я хочу попросить помощи в следующей ситуации! У меня есть сервер: CPU Intel® Xeon® E5320 @ 1.86GHz 2шт x 4 ядра Мат. плата Intel S5000PSL 2 встроенных сетевых адаптера Intel 82563EB Внешние сетевые адаптеры Intel 82541, Intel 82544, HP BCM5706 (2 порта). На маршрутизаторе используется 2 сетевые карты. Одна смотрит в сторону пограничного маршрутизатора, вторая - в сторону клиентов. В примере указано больше сетевых адаптеров, т.к. я тестировал проблему в различных комбинациях сетевых интерфейсов, но нужно два сетевых интерфейса. uname -a Linux localhost 4.11.3-1-ARCH #1 SMP PREEMPT Sun May 28 10:40:17 CEST 2017 x86_64 GNU/Linux __________________________________________ Intel 82563EB driver: e1000e version: 3.2.6-k firmware-version: 1.0-0 [root@localhost ~]# ethtool -c enp4s0f0 Coalesce parameters for enp4s0f0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 3 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 __________________________________________ Intel 82541, Intel 82544 driver: e1000 version: 7.3.21-k8-NAPI [root@localhost ~]# ethtool -c enp5s1 Coalesce parameters for enp5s1: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 0 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 __________________________________________ HP BCM5706 driver: bnx2 version: 2.2.6 firmware-version: bc 1.9.6 [root@a-gw ndu]# ethtool -c net1 Coalesce parameters for net1: Adaptive RX: off TX: off stats-block-usecs: 999936 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 18 rx-frames: 12 rx-usecs-irq: 18 rx-frames-irq: 2 tx-usecs: 80 tx-frames: 20 tx-usecs-irq: 18 tx-frames-irq: 2 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 Я провожу стресс тест на количество пропускаемых пакетов сетевой картой. Входящие пакеты любым сетевым адаптером равномерно распределяются между ядрами при любой нагрузке. Исходящие пакеты равномерно распределяются между ядрами только при нагрузке менее 500 тыс. пакетов/сек. Если нагрузка исходящего трафика превышает порог 500 тыс. пакетов/сек, то одно из ядер забивается на 100%. В этом случае на этой сетевой карте затормаживается обработка пакетов, пока нагрузка не упадет. Сетевые карты проверял в различных комбинациях. Кольцевые буферы выставлял на максимум - результат не меняется. Я еще раз повторю, что ядро забивается в случае отправки пакетов, а не приема. Я обнаружил, что проблема возникает во всех случаях, кроме случае прохождения пакета пакет-->внешний сетевой адаптер-->OS Linux-->внутренний сетевой адаптер. Однако практически во всех других комбинациях наблюдается эта проблема. Почему почти? Потому-что я не могу досконально утверждать, что все комбинации проверял, ведь сетевая карта HP BCM5706 используется под нагрузкой. Вот пример проблемной ситуации Every 1.0s: cat /proc/softirqs localhost: Mon Jun 19 13:05:31 2017 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 HI: 0 1 0 4 0 0 0 0 TIMER: 18766 17311 21781 36072 18429 14728 14850 17759 NET_TX: 218 1208 250 114181 720 257 243 511 NET_RX: 3611784 3595720 3608193 3697658 3542628 3540516 3553108 3531652 BLOCK: 2318 1691 1652 1881 1995 1583 2107 2025 IRQ_POLL: 0 0 0 0 0 0 0 0 TASKLET: 2601 2669 2600 2696 2635 2656 2606 2660 SCHED: 15465 13632 14378 16157 14260 10967 11437 13048 HRTIMER: 0 0 0 0 0 0 0 0 RCU: 9876 9856 15880 17163 10356 8367 8260 12001 Every 1.0s: cat /proc/interrupts| grep enp localhost: Mon Jun 19 13:06:50 2017 25: 2126060 2090503 2151377 2113891 2125791 2150314 2128414 2140061 IO-APIC 1-fasteoi enp5s1 (Счётчики в момент ступора ядра останавливаются) 26: 6765 6982 6726 6883 6968 6856 6731 6898 PCI-MSI 2097152-edge enp4s0f0 28: 1251194 1285380 1225995 1262559 1250625 1226919 1248457 1236982 PCI-MSI 2099200-edge enp4s0f1 (Счётчики в момент ступора ядра останавливаются) ATOP PRC | sys 3.01s | user 0.02s | | | #proc 146 | #trun 2 | #tslpi 134 | | #tslpu 0 | #zombie 0 | clones 10 | | | #exit 10 | CPU | sys 1% | user 1% | | irq 100% | | idle 698% | wait 2% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 100% | | idle 0% | cpu003 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 1% | | irq 0% | | idle 99% | cpu000 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 100% | cpu001 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 98% | cpu004 w 1% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | cpu | sys 0% | user 0% | | irq 0% | | idle 100% | cpu006 w 0% | | | steal 0% | guest 0% | curf 1.87GHz | | curscal ?% | CPL | avg1 0.80 | | avg5 0.42 | avg15 0.33 | | | | csw 413 | | intr 1446 | | | numcpu 8 | | MEM | tot 3.9G | free 3.7G | cache 48.4M | dirty 0.1M | buff 15.4M | slab 60.0M | slrec 36.0M | shmem 0.6M | shrss 0.0M | shswp 0.0M | vmbal 0.0M | | hptot 0.0M | hpuse 0.0M | SWP | tot 16.0G | free 16.0G | | | | | | | | | | vmcom 38.4M | | vmlim 17.9G | MDD | md1 | busy 0% | | read 0 | write 3 | | KiB/r 0 | KiB/w 4 | MBr/s 0.0 | | MBw/s 0.0 | avq 0.00 | | avio 0.00 ms | DSK | sda | busy 4% | | read 0 | write 8 | | KiB/r 0 | KiB/w 2 | MBr/s 0.0 | | MBw/s 0.0 | avq 1.10 | | avio 15.9 ms | DSK | sdb | busy 4% | | read 0 | write 8 | | KiB/r 0 | KiB/w 2 | MBr/s 0.0 | | MBw/s 0.0 | avq 1.13 | | avio 15.8 ms | NET | transport | tcpi 4 | tcpo 4 | udpi 0 | | udpo 0 | tcpao 0 | tcppo 0 | tcprs 0 | tcpie 0 | tcpor 0 | | udpnp 0 | udpie 0 | NET | network | ipi 1053809 | | ipo 1053800 | ipfrw 1054e3 | | deliv 12 | | | | | icmpi 0 | | icmpo 0 | NET | enp4s0f 8% | pcki 526904 | pcko 526887 | | sp 1000 Mbps | si 89 Mbps | so 89 Mbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | enp5s1 8% | pcki 526912 | pcko 526857 | | sp 1000 Mbps | si 84 Mbps | so 84 Mbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | NET | enp4s0f 0% | pcki 33 | pcko 4 | | sp 100 Mbps | si 7 Kbps | so 5 Kbps | | coll 0 | mlti 0 | erri 0 | erro 0 | drpi 0 | drpo 0 | Прикреплено вложение вывода htop Вопросы: Почему ОС Linux в случае отправки пакетов при превышении указанного порога начинает задействовать только одно ядро (есть незначительная загрузка других ядер)? Может достигнута пропускная способность какой-либо шины материнской платы? Почему в момент перегрузки останавливаются счетчики /proc/interrupts ? Если не сможем разобраться, то есть другой вариант - использовать сервер HP G5 ntel® Xeon® CPU X5260 @ 3.33GHz со встроенными адаптерами BCM5708. На нем этой проблемы нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 20 июня, 2017 · Жалоба Для начала купите нормальные сетевые, а эти все в помойку, насколько я помню, все они без очередей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 20 июня, 2017 · Жалоба насколько критичен для софтроутера размер arp-таблицы? у меня уже 600+, будет расти (не провайдер). можно, конечно, перетащить роутинг между сегментами сети на l3-свитч, но мне удобнее, когда всё в одном месте конфигурируется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...