是否有人有一些数据或基本计算可以回答何时需要帧合并(NAPI)以及每帧单个中断何时就足够了?
我的硬件:IBM BladeServer HS22,Broadcom 5709 千兆位 NIC 硬件(MSI-X),配备双 Xeon E5530 四核处理器。主要用途是 Squid 代理服务器。交换机是不错的 Cisco 6500 系列。
我们的基本问题是,在高峰时段(100 Mbps 流量,仅 10,000 pps),延迟和数据包丢失会增加。我进行了大量调整并将内核升级到 2.6.38,这改善了数据包丢失,但延迟仍然很差。Ping 是不稳定的;在本地 Gbps LAN 上甚至会跳到 200ms。即使 CPU/内存负载正常,Squid 平均响应时间也会从 30ms 跳到 500+ms。
在峰值期间,中断率攀升至每秒约 15,000 次。Ksoftirqd 不会占用太多 CPU;我安装了 irqbalance 来平衡所有核心的 IRQ(eth0 和 eth1 各 8 个),但这并没有多大帮助。
英特尔网卡似乎从来没有出现过这类问题,但由于刀片系统和固定配置硬件的存在,我们只能使用博通。
一切都表明 NIC 是罪魁祸首。我现在最好的想法是尝试减少中断,同时保持低延迟和高吞吐量。
不幸的是,bnx2 不支持自适应 rx 或 tx。
这NAPI 与自适应中断线程答案提供了中断调节的一个很好的概述,但没有关于如何计算给定解决方法的最佳 ethtool 合并设置的具体信息。除了反复试验,有没有更好的方法?
上述工作负载和硬件配置是否真的需要 NAPI?或者它是否应该能够依靠每个数据包的单个中断生存?
答案1
这个问题问得好,让我读了一些书,试图弄清楚。希望我能说我有答案……但也许有一些提示。
我至少可以回答你的问题,“它是否能够在每个数据包的单个中断上存活”。我认为答案是肯定的,基于我可以访问的非常繁忙的防火墙:
SAR 输出:
03:04:53 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
03:04:54 PM lo 93.00 93.00 6.12 6.12 0.00 0.00 0.00
03:04:54 PM eth0 115263.00 134750.00 13280.63 41633.46 0.00 0.00 5.00
03:04:54 PM eth8 70329.00 55480.00 20132.62 6314.51 0.00 0.00 0.00
03:04:54 PM eth9 53907.00 66669.00 5820.42 21123.55 0.00 0.00 0.00
03:04:54 PM eth10 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth11 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth2 146520.00 111904.00 45228.32 12251.48 0.00 0.00 10.00
03:04:54 PM eth3 252.00 23446.00 21.34 4667.20 0.00 0.00 0.00
03:04:54 PM eth4 8.00 10.00 0.68 0.76 0.00 0.00 0.00
03:04:54 PM eth5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth6 3929.00 2088.00 1368.01 183.79 0.00 0.00 1.00
03:04:54 PM eth7 13.00 17.00 1.42 1.19 0.00 0.00 0.00
03:04:54 PM bond0 169170.00 201419.00 19101.04 62757.00 0.00 0.00 5.00
03:04:54 PM bond1 216849.00 167384.00 65360.94 18565.99 0.00 0.00 10.00
如您所见,每秒的数据包数量非常高,并且这台机器没有进行任何特殊的 ethtool 调整。哦...不过是英特尔芯片组。:\
唯一完成的是使用 /proc/irq/XXX/smp_affinity 在每个接口上进行手动 irq 平衡。我不确定他们为什么选择这种方式而不是使用 irqbalance,但它似乎有效。
我也考虑过回答你的问题所需的数学知识,但我认为变量太多了。所以……总而言之,在我看来,答案是否定的,我认为你无法预测结果,但只要有足够的数据捕获,你就应该能够将其调整到更好的水平。
尽管如此,我的直觉是,你在这里在某种程度上受到了硬件的限制……就像某种固件或互操作错误一样。
答案2
当然,考虑到 CPU、芯片组和总线功能,与如此低的流量相比,您根本没有理由需要任何形式的中断管理。我们有多台 RHEL 5.3 64 位机器,配有 10Gbps NIC,它们的中断一点也不差,这个要少 100 倍。
显然,您有一个固定配置(我使用非常相似的 HP 刀片),因此将 NIC 换成 Intel NIC 现在是一种简单的选择,但我想说的是,我开始在这个论坛和其他地方发现该特定 Broadcom NIC 存在许多类似的问题。SE 网站本身也曾遇到过这种不一致的问题,而换成 Intel NIC 绝对有帮助。
我的建议是选择一台单刀片,然后为这台机器添加一个基于 Intel 的适配器,你显然必须添加一个互连或 IBM 所称的任何设备才能发出信号,但请尝试使用相同的软件设置,但使用另一个 NIC(如果可以,最好禁用 Broadcom)。测试一下,看看效果如何,我知道我所描述的需要一些额外的硬件,但我想你的 IBM 代表会很乐意借给你。这是唯一可以确定的方法。请让我们知道你发现了什么,我真的很想知道这些 NIC 是否有问题,即使这是一个奇怪的极端情况。顺便说一句,我下周要和 Intel 和 Broadcom 会面,讨论一些完全不相关的事情,但我一定会和他们讨论,如果我发现任何有趣的东西,我会告诉你。
答案3
关于中断的问题是它们如何影响整个系统性能。中断可以抢占用户和内核空间处理,虽然您可能看不到太多的 CPU 使用率,但会发生大量上下文切换,这对性能有很大影响。您可以使用vmstat
并检查system
列标题,cs
了解每秒的中断和上下文切换次数(中断包括时钟,因此您必须将其考虑在内),这也值得检查。
答案4
后续内容:卸载 NAT 和 conntrack 模块并最小化 iptables 规则集后,我们获得了出色的性能。IPVS 负载平衡器已达到 900 Mbps / 150 kpps 以上。这还是在使用相同的 Broadcom bnx2 芯片组的情况下实现的。
因此得出结论:中断处理似乎很好,并且带有 2.6.38/3.0.x 内核的 Debian 的默认设置似乎表现得可以接受。
我当然更愿意使用英特尔网卡,这样我们就可以使用标准的 Debian 软件包。对抗非免费的 bnx2 固件是巨大的时间浪费。