如何在不使用巨型数据包的情况下提高 Intel X520-DA2 10Gb NIC 吞吐量

如何在不使用巨型数据包的情况下提高 Intel X520-DA2 10Gb NIC 吞吐量

以下是我目前所做的:

使用更多 Rx/Tx 缓冲区可最大程度地提高性能。我在每个适配器上将 RSS 队列设置为 4,并将第二个端口上的起始 RSS CPU 指定为 0 以外的值(在我使用的 PC 上为 16,具有 16 个内核、32 个 HT)。

从观察 ProcessExplorer 来看,即使启用了 RSS,CPU 处理大量传入中断的能力也受到限制。我在 2.x 模式下使用 PCIe x8(电气)插槽。两个适配器中的每一个都与 5GT/秒 x8 总线连接。

操作系统响应能力并不重要,I/O 吞吐量才是关键。我受到客户端无法处理巨型数据包的限制。

下一步我应该尝试哪些设置?

详细信息:双 Xeon-E5 2665、32 GB RAM、RAID0 中的八个 SSD(RAMDrive 用于 NIC 性能验证)、1TB 数据将通过 IIS/FTP 从 400 个客户端尽快移动。

回复评论:

通过一对 10Gb/秒的链路,实际读取吞吐量为 650 MB/秒,进入 RAM 驱动器

据我所知,防病毒软件和防火墙已关闭。(在这种情况下,我可以很好地控制 PC 上安装的内容。我如何确保没有过滤器会降低性能?我必须跟进,说得好。)

在 Process Explorer 中,我看到一段时间内 CPU 持续运行(红色,内核时间),但网络和磁盘 I/O 停止

最大 RSS 处理器数量为默认值 16

X520-DA2 设备的两个实例都支持消息信号中断,MessageNumberLimit 设置为 18。这是我在低端台式机卡上看到的内容

检查 MSI 支持的方法

ProcExp 摘要

在此处输入图片描述

答案1

高性能 NIC 的问题之一是现代 PC 架构有点跟不上。但就您而言,这并不是什么大问题。让我解释一下。

CPU 必须做大量工作来处理 TCP 数据包。这会影响吞吐量。在您的情况下,限制因素不是网络硬件,而是服务器使网络链路饱和的能力。

最近,我们看到处理从 CPU 转移到 NIC,例如校验和卸载。英特尔还增加了一些功能来帮助进一步减少负载。这很酷,我相信所有优化功能都已启用。

正如你提到的,巨型帧实际上有助于提高吞吐量。但不如远程直接内存访问 (RDMA)

大多数 10GBit 以太网硬件都具有一项非常好的未充分利用的功能,称为 RDMA 或远程直接内存访问。它允许 NIC 通过网络进行内存到内存的复制,而无需 CPU 的干预。好吧,CPU 告诉 NIC 要做什么,然后 NIC 完成其余的工作。问题是,它还没有得到广泛使用。但它正在实现这一点。显然,在最新版本的 Microsoft Windows Server 2012 中,他们有一个叫做中小企业直连。它使用 RDMA。因此,如果你想增加吞吐量,你就需要使用它。

您能否组装一些测试硬件并将其安装到那里以查看其性能?

顺便说一句,我不确定您是否会在 10Gbit 上看到这么多,但快速 RAM 有助于 RDMA,尤其是使用 56Gbit Infiniband 时。一般来说,最好使用服务器支持的最快 RAM。

还请注意我上面放置的 SMB Direct 链接上的这条评论:

如果您打算使用网络适配器的 RDMA 功能,则不应将支持 RDMA 的网络适配器组合在一起。组合后,网络适配器将不支持 RDMA。


更新:由于某些原因,似乎并非所有 10GBit NIC 都支持 RDMA。因此请先检查您型号的功能。

我的另一个想法是,用于进行测试的协议类型可能会影响结果。即 TCP 开销之上的协议开销。我建议您考虑使用无需接触硬盘即可进行测试的工具,例如 iperf。某个地方有它的 Windows 端口。

答案2

我认为这个问题:为什么我的千兆位链路无法提供至少 150 MB/s 的吞吐量?与您的问题有关。我当时谈论的是 Dell PowerEdge 6950。答案基本上是“使用巨型帧”来减少中断。我可以想象,调整网卡的卸载引擎可能会对您有所帮助,但我不知道如何在 W2K8R2 上做到这一点。

主意: 增加网卡中的缓冲区数量,提高缓冲区中数据包的中断触发器,以便每个中断将处理更多的数据包(即将它们传递给 OS-IP 堆栈)。

请参阅此链接:使用 ethtool 设置 10 Gb 的合并参数这基本上就是我所指的。

答案3

您的 CPU 利用率屏幕截图显示了 2 个潜在瓶颈:

  1. 4 个核心最大限度执行内核工作(例如,可能中断处理程序处理数据包)
  2. 1 个核心主要处于用户模式

为了解决前者:

  • 尝试更改中断审核设置,根据您的驱动程序,它不仅仅是打开/关闭,您可能能够设置审核策略
  • 尝试禁用/启用所有卸载功能(对于您而言,禁用可能会有所帮助,这样可以将潜在的瓶颈从您的(单核)NIC(功能将被卸载到)转移到您的(多核)处理器)
  • 尝试启用“接收合并”(接收 TCP 时),以及驱动程序可能提供的各种“大型接收...”、“大型传输...”等功能
  • 您不能将 RSS 队列设置为高于 4 的值吗?似乎只有 2 个端口中的一个正在使用(正如您所说,您知道这一点,我假设您将第二个端口设置为至少 4(或 8,不确定是否要计算 HT)
  • 如果可能,请增加使用的不同 TCP/UDP 端口的数量,或 IP 源/目标地址,因为无论 RSS 设置如何,一个地址/端口/协议 5 元组(或非 TCP/UDP 流量的地址/协议 3 元组)始终必须转到同一个核心

至于后者(不知道您实际使用什么应用程序):

如果用户模式下 1 个核心的极限表明你的应用程序是单线程(或单线程瓶颈),那么应该是

  • 固定,或
  • 重新配置(例如,如果可能的话增加工作线程数),或者
  • 重新设计

使用多个核心,这可能是也可能不是微不足道的。

另外,由于你的应用程序(如果它确实是你的程序)显然在 NUMA 节点 #1 上运行,但内核的数据包处理是在 NUMA 节点 #0 上完成的,

  • 尝试将应用程序关联到 NUMA 节点 #0

例如,右键单击任务管理器中的进程,这将为您提供更改该选项,至少在 Win2012R2 中是这样。我试过了,对我来说没有帮助,但值得一试,因为它可能会提高缓存命中率。

顺便问一下,这台机器是发送还是接收?还是两者都有?就配置系统性能而言,发送和接收几乎完全不相关,尽管我上面的建议涵盖了两者。

相关内容