У нас есть брандмауэр Linux с двумя обращенными наружу адаптерами 10Gbe (Intel 82599EB) и одним адаптером 10Gbe, обращенным внутрь (Intel 82598EB).
Проблема, с которой я столкнулся, заключается в том, что брандмауэр будет пересылать входящий трафик только с очень низкой скоростью: примерно <2 Мбит / с. Однако прямое соединение брандмауэра с «внутренней» машиной дает ~ 6 Гбит / с, а прямое соединение с брандмауэром с внешней машины составляет ~ 1 Гбит / с. Есть некоторые настройки, которые нужно сделать четко, но они демонстрируют скорость Гбит / с.
Недавно мы обновили Intel ixgbe драйвер с версии 2.1.4 до 3.7.14 из-за проблем со стабильностью с драйвером 2.1.4 (блокировки), и, похоже, именно тогда начались проблемы с пропускной способностью.
Я также попробовал версию 3.7.17, но она показала ту же производительность, что и 3.7.14. При возврате к драйверу 2.1.4 (перекомпилированному для обновленного ядра с IXGBE_NO_LRO и IXGBE_NO_NAPI) я смог получить пропускную способность ~ Гбит / с (хорошо ~ 900 Мбит / с с iperf over TCP с 3 потоками).
Это решает непосредственную проблему, но я бы предпочел иметь возможность использовать текущую версию драйвера, поскольку я хотел бы быть в курсе исправлений ошибок и т. Д., Поэтому мой вопрос:
В частности, как я могу узнать, где ядро / iptables / сетевой драйвер и т.д. тратят свое время при пересылке пакетов?
Любой соответствующий совет будет оценен.
Действительно странно, что вы получаете только 1 Гбит / с производительности маршрутизации (даже жесткая фильтрация обычно означает 2 копии из пространства ядра для одного и того же устройства, вероятно, 4x для маршрутизации) - год назад был пост LKML, что вы можете получить производительность маршрутизации 120 Гбит / с на серии 2.6.3X с ixgbe устройств. Я в основном использую сетевые карты Intel 10GbE и обычно получаю 1000 МБ / с + с iperf через коммутируемую инфраструктуру.
Сначала вам нужно проверить, как система работает для простого TCP с чем-то вроде iperf между вашими конечными точками. Это должно дать вам базовый уровень. Помните, что многое нужно сделать, если вам нужна скорость передачи данных 10 Гбит / с. На платформах до Nehalem этого даже невозможно достичь. Кроме того, системная нагрузка должна соответствовать схеме NUMA, а сетевые адаптеры должны быть подключены к одному и тому же PCI-комплексу (это важно, если вы застряли на скорости <8 Гбит / с). В исходном дистрибутиве ixgbe есть сценарий закрепления IRQ (который также отключает такие вещи, как энергосбережение и irqbalancer, который только портит кеши и не учитывает топологию), который должен распределять очереди RX-TX равномерно по всем ядрам (не проверял их через некоторое время).
Что касается вашего вопроса о таймингах, вам понадобится ядро, скомпилированное с поддержкой профилирования, и профилировщик системного уровня, например oprofile.
Перед тем, как включить фильтрацию или маршрутизацию пакетов и опубликовать это, проверьте производительность конечной точки и конечной точки.
Несколько месяцев назад я приложил немало усилий для оптимизации Linux для высокоскоростной гигабитной маршрутизации с большим количеством небольших пакетов. Это было для балансировщика нагрузки (IPVS), а не для межсетевого экрана NAT. Вот несколько советов, основанных на этом.
Я еще не видел разбивки по времени, затрачиваемому на сетевые функции ядра, такие как переключение против маршрутизации против брандмауэра против чего угодно.
Iptables - действительно эффективный межсетевой экран для систем Linux. Он может обрабатывать огромный объем трафика, не создавая узких мест, если вы написали хороший набор правил.
Вы можете отключить iptables, сбросив все правила и установив значение по умолчанию. FORWARD политика к ACCEPT. Таким образом вы избавитесь от каких-либо проблем с реализацией iptables. После этого вы можете посмотреть сетевой драйвер и попытаться устранить проблему, если она не исчезнет.
В качестве совета: будьте осторожны и не отключайте iptables на общедоступной машине, если вы не знаете, что делаете.
Производительность односторонней заливки может быть вызвана проблемами с разгрузкой сегментации TCP и другими настройками сетевого адаптера. Это может быть замечено во многих случаях, например, с трафиком виртуальной машины или VPN, проходящим через физический сетевой адаптер. Его легко отключить с помощью ethtool и проверить производительность, поэтому стоит попробовать (убедитесь, что вы отключили его на обеих конечных точках для тестирования).
/usr/sbin/ethtool -K eth0 tso off
/usr/sbin/ethtool -K eth0 lro off
Вот еще немного предыстории:
http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/ https://social.technet.microsoft.com/Forums/windowsserver/en-US/bdc40358-45c8-4c4b-883b-a695f382e01a/very-slow-network-performance-with-intel-nic-when-tcp-large- send-offload-is-включен? forum = winserverhyperv