31.4. 提高大量连续数据流的吞吐量


根据 IEEE 802.3 标准,没有 Virtual Local Area Network (VLAN)标签的默认以太网帧最大大小为 1518 字节。这些帧的每一个都包含一个 18 字节标头,为有效负载保留 1500 字节。因此,对于服务器通过网络传输的每个 1500 字节数据,就有 18 字节(1.2%)以太网帧标头的开销,并也会被传输。第 3 层和 4 协议的标头进一步增加了每个数据包的开销。

如果您网络上的主机经常发送大量连续的数据流,如备份拥有多个巨型文件的服务器或文件服务器,则考虑使用巨型帧来节省开销。巨型帧是非标准帧,其比 1500 字节的标准以太网有效负载有更大的最大传输单位(MTU)。例如,如果您使用最大允许 9000 字节有效负载的 MTU 配置巨型帧,则每个帧的开销减少到 0.2%。

根据网络和服务,仅在网络的特定部分(如集群的存储后端)启用巨型帧会很有帮助。这可避免数据包碎片。

31.4.1. 配置巨型帧前的注意事项

根据您的硬件、应用程序及网络中的服务,巨型帧可能有不同的影响。仔细决定在您的场景中启用巨型帧是否会带来好处。

先决条件

传输路径上的所有网络设备必须支持巨型帧,并使用相同的最大传输单元(MTU)大小。否则,您可能遇到以下问题:

  • 丢弃的数据包。
  • 由于碎片数据包,延迟更高。
  • 增加由碎片导致的数据包丢失的风险。例如,如果路由器将一个 9000 字节帧分为六个 1500 字节帧,并且所有这些 1500 字节帧都丢失了,则整个帧都会丢失,因为它无法重新组装。

在下图中,如果来自网络 A 的主机向网络 C 中的主机发送数据包,则这三个子网中的所有主机都必须使用同样的 MTU:

网络图 MTU

巨型帧的好处

  • 更高的吞吐量:每个帧包含更多的用户数据,同时修复了协议开销。
  • CPU 使用率较低:巨型帧导致较少的中断,因此可以节省 CPU 周期。

巨型帧的缺陷

  • 更高的延迟:大帧会延迟后面的数据包。
  • 增加了内存缓冲区使用率:大帧可以更快地填充缓冲区队列内存。

31.4.2. 在现有 NetworkManager 连接配置文件中配置 MTU

如果您的网络需要与默认值不同的最大传输单元(MTU),您可以在相应的 NetworkManager 连接配置文件中配置此设置。

巨型帧是,有效负载为 1500 到 9000 字节的网络数据包。同一广播域中的所有设备都必须支持这些帧。

先决条件

  • 广播域中的所有设备都使用同样的 MTU。
  • 您了解网络的 MTU。
  • 您已为具有发散 MTU 的网络配置了连接配置文件。

流程

  1. 可选:显示当前的 MTU:

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
  2. 可选:显示 NetworkManager 连接配置文件:

    # nmcli connection show
    NAME     UUID                                  TYPE      DEVICE
    Example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
    ...
  3. 在管理到带有分散 MTU 的网络的连接的配置文件中设置 MTU:

    # nmcli connection modify Example mtu 9000
  4. 重新激活连接:

    # nmcli connection up Example

验证

  1. 显示 MTU 设置:

    # ip link show
    ...
    3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 52:54:00:74:79:56 brd ff:ff:ff:ff:ff:ff
    ...
  2. 验证传输路径上的主机没有对数据包进行碎片处理:

    • 在接收方一侧,显示内核的 IP 重组统计信息:

      # nstat -az IpReasm*
      #kernel
      IpReasmTimeout 0 0.0
      IpReasmReqds 0 0.0
      IpReasmOKs 0 0.0
      IpReasmFails 0 0.0

      如果计数器返回 0,则数据包不会重组。

    • 在发送方一侧,使用 prohibit-fragmentation-bit 传输 ICMP 请求:

      # ping -c1 -Mdo -s 8972 destination_host

      如果命令成功,则不会对数据包进行碎片处理。

      按如下所示计算 -s 数据包大小选项的值:MTU size - 8 字节 ICMP 标头 - 20 字节 IPv4 header = 数据包大小

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.