如何使用 Intel 10 Gbe 排除 Linux 路由器/防火墙转发性能故障?

如何使用 Intel 10 Gbe 排除 Linux 路由器/防火墙转发性能故障?

我们有一个 Linux 防火墙,它有两个面向外的 10Gbe 适配器(Intel 82599EB)和一个面向内的 10Gbe 适配器(Intel 82598EB)。

我遇到的问题是防火墙只能以非常低的速率转发入站流量:大约 < 2 Mbps。但是,从防火墙到“内部”机器的直接连接速度约为 6 Gbps,而从外部机器到防火墙的直接连接速度约为 1 Gbps。显然需要进行一些调整,但它们展示了 Gbps 的速度。

ixgbe由于 2.1.4 驱动程序存在稳定性问题(锁定),我们最近将英特尔驱动程序从 2.1.4 版更新至 3.7.14 版,这似乎是吞吐量问题开始出现的时候。

我也尝试了 3.7.17 版本,但它的性能与 3.7.14 类似。在恢复到 2.1.4 驱动程序(针对更新的内核重新编译,使用 IXGBE_NO_LRO 和 IXGBE_NO_NAPI)时,我能够获得 ~Gbps 吞吐量(使用 3 个线程通过 TCP 使用 iperf 时,吞吐量约为 ~900 Mbps)。

这解决了眼前的问题,但我更愿意使用当前版本的驱动程序,因为我想及时修复错误等。所以我的问题是

  • 如何排除 Linux 路由器/防火墙转发性能故障?

具体来说,我如何才能找出内核/iptables/网络驱动程序等在转发数据包时花费的时间?

任何相关建议都将不胜感激。

答案1

真的很奇怪,你只能获得 1 Gbps 的路由性能(即使严格的过滤通常意味着同一设备的内核空间中有 2 个副本,路由可能需要 4 倍)——一年前有一篇 LKML 帖子说你可以在 2.6.3X 系列设备上获得 120Gbps 的路由性能ixgbe。我主要使用 Intel 10GbE NIC,通常通过iperf交换基础设施获得 1000MByte/s+。

首先,您需要使用 iperf 之类的工具检查系统在端点之间对普通 TCP 的执行情况。这应该会给您一个基准。请记住,如果您需要 10Gbps 线速,则有很多因素需要考虑。在 Nehalem 之前的平台上,这甚至是不可能实现的。此外,系统负载应与 NUMA 布局相匹配,并且 NIC 必须连接到相同的 PCI 复合体(如果您的速度被卡在 < 8 Gbps,这一点很重要)。ixgbe 源发行版有一个 IRQ 固定脚本(它还会禁用诸如省电和 irqbalancer 之类的功能,这只会弄乱缓存并且不了解拓扑),它应该将 RX-TX 队列均匀地分布在所有核心上(有一段时间没有检查它们了)。

关于时间的问题,您需要一个使用分析支持编译的内核以及类似的系统级分析器oprofile

在启用数据包过滤或路由并发布之前,请先解决端点到端点的性能问题。

答案2

几个月前,我投入了大量精力来优化 Linux,以实现具有大量小数据包的线速千兆路由。这是针对负载平衡器 (IPVS) 而不是 NAT 防火墙。以下是基于此的一些提示。

  • 将 Linux 内核升级到至少 2.6.30(我们需要更新的 Broadcom bnx2 驱动程序)
  • 使用 ifconfig 查看接口是否存在任何类型的错误/丢失/等等
  • 下载并编译最新的 ethtool,以确保它完全支持你的 NIC 驱动程序
  • 使用 ethtool 查找更详细的统计数据
  • 使用 ethool 调整合并、NAPI 等设置以最大限度地减少中断
  • 查看 irqbalance 以确保它们在 CPU 核心之间保持平衡
  • 看看像 ksoftirqd 这样的内核线程...它们是否使用了大量 CPU?
  • 通过使用 rmmod 卸载内核模块来完全禁用 iptables。尤其是 NAT 和 conntrack 可能会产生巨大的负面影响,即使您已经清除了所有规则并且链为空。这样做后,我发现性能有了很大的提升。您提到这是一个防火墙,但我仍然会暂时卸载 NAT 和 conntrack 模块,看看是否有什么不同。

我还没有看到每个内核网络功能(例如交换、路由、防火墙等等)所花费时间的细分。

答案3

Iptables 是 Linux 系统上非常有效的防火墙。只要你编写了良好的规则集,它就可以处理大量流量而不会出现瓶颈。

您可以做的一件事是通过刷新所有规则并将默认FORWARD策略设置为来禁用 iptables ACCEPT。这样您就可以消除对 iptables 实现的任何担忧。之后,您可以查看网络驱动程序并尝试调试问题(如果问题仍然存在)。

建议:请小心,不要在可公开访问的机器上禁用 iptables,除非您知道自己在做什么。

答案4

单向流性能可能是由 tcp 分段卸载和 NIC 上的其他设置问题引起的。它可能在许多情况下被发现,例如当 VM 或 VPN 流量通过物理 NIC 时。使用 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-enabled?forum=winserverhyperv

相关内容