鸟哥私房菜 - 使用 10G switch 需要注意的性能问题

最近更新时间： 2019/02/13

最近这三、四年来，网络的使用频率越来越高，加上虚拟化与共用文件系统的任务，因此网络的带宽越来越重要！传统的 10G 以上设备，光是光纤就贵森森，因此，最近这几年来，大量的 RJ-45 接头的 10G 设备的支持，就显得很重要！因为，可以向下兼容 1Gbps 的设备之外，带宽可以增加 10 倍哩！只是，这种 10G, Gbps 的共存环境下，其实存在某些很特别的问题，大部分的时间你不会注意到，但是，如果你使用的环境跟鸟哥一样时，你可能会发现， 10G switch 似乎没有想像中的可靠！原因就让我们看下去！

1、环境架构与问题
2、寻找问题的方向
3、flow control (switch and NIC)
4、其他调校 (ring buffer and queue number)
5、结语与参考数据

1、环境架构与问题

鸟哥所在的场域中，因为有 5 间电脑教室以及一间服务器机房，其中机房有一台全部的电脑都会取用的 Samba 系统，这部系统里面供应了全系四百多位师生的 windows 个人家目录数据，以及师生们共用的教材环境，因此，您可以知道这个系统有多重要！在 2 年前，大概是在 2017 年以前，我们使用的是 bonding 的技术，在这部系统上面安插了两张 4 port 的 giga NIC，加上系统本身有两个 giga port，用 10 个 giga port 搭配，组合成一个 bonding 的技术。即使如此，还是无法解决越来越重的负担。

10G 环境的设计

为此，在 2017 年以后，趁着系上有一笔教学经费，于是将整个系上教学用的骨干网络重新设计一番！我们采用了 10G 骨干设计，通过两个 12 port 的 10G switch，串连 5 间电脑教室的 router 系统，而且严格控制进入骨干网络的封包，排除 UDP 的封包，只让 port 0~1024 以及我们系上自己的某些服务会用到的端口口，仅放行这些重要的资源，其他的封包全部禁止进入该网络！因此，这个 10G 的环境相对的安静，只让系上的师生上课时，可以使用方便快捷的骨干网络！上课重要！整体架构有点像底下这样：

大致的设计如上图，因为我们系上是在一个平面上，只是教室之间的距离比较远，所以不太可能 5 间教室全部的 10G 线路都拉到一起，那太复杂了！于是分成两个部份，如上图所示，左上方的 10G switch 主要链接两间大教室 (电脑总数量约 110 台) 与 Samba server 所在的机房 (这个系统最重要)，然后右下角的 10G switch 则是链接其他三间电脑教室 (电脑总数量约 80 台)，两个 switch 之间则串接在一起而已。

至于每一间电脑教室的 router (其实我们都称呼防火墙系统) 上面有三个网络界面：

10G 界面，直接连接到 10G switch (骨干界面)
10G 界面，连接到教室内的 2 port 10G 与 24 ~ 48 port Gb switch
Gb 界面，直接连到对 Internet 的计中网络环境。

请看上图的 Class A 部份，防火墙系统与骨干是以 10G 的速度相连，与内部所有的系统则提供 10G 的速度。而每一台学生上课用电脑则仅有 Gb 界面，但是全部的系统可以共用 10G 的速度，此外，那一部 Samba 服务器 (最上方)，则提供两个 10G 网卡，搭配成为 bonding 界面，假设可以提供共 20G 的流量～当然，我们知道这不可能！因为单点对单点只能使用到一张网卡！但是在两间教室同时使用时，则可能可以提供 20G 的流量 (只是理论上！实际上差很多)。

因为上课时，最重要的情况就是学生电脑对 Samba server 的数据传输，从 2017 年以来，有四个班同时上课时，同时取用 Samba 的数据，似乎也没有什么太大的问题！使用上相当顺畅的！

网络带宽问题的产生： scp 的速度很慢

虽然使用上没有什么太大的问题，但是，每学期初，我们的学生都需要将用户端电脑进行大量的裸机复原，也就是说，通过上图的防火墙系统，搭配 DRBL 相关的机制，让总数大约将近 200 台电脑，在各间教室各自的复原，复原的动作是这样的：

各教室都各拿一台主机来安装多重操作系统 (一个上课用，一个考试用)
安装系统完毕，都需要进行授课软件的安装、系统升级、需要环境调整等等
上课环境安装妥当之后，通过类似 DRBL + clonezilla 环境，将上述的 Demo 环境『备份』的防火墙系统上
每一台用户端电脑，通过类似 DRBL + clonezilla 环境，进行所有电脑的裸机复原。

乍看之下这样很顺畅啊～都没有问题！确实，第 3 步骤上传到防火墙系统速度是正常的，但是，我们发现第 4 步骤突然变很慢，甚至可能比以前仅有 giga 速度时还要慢的情境！学生们觉得很不可思议！毕竟是 10G 了耶！后来使用 scp 指令进行测试，我们发现到：

从 1Gb --> 10G 时，传输速度可以到达 100Mbytes/s ！
从 10G --> 1Gb 时，传输速度却仅有 40Mbytes/s 以下！

原本我们猜测与 scp 拷贝时需要的加密机制有关 (注1)，不过，由于近期来的 CPU 都有加上 AES 硬件加解密的机制，而我们的 CPU 检查之下，确实都有支持 AES flag，如下所示：

[root@client ~]# grep  aes /proc/cpuinfo | head -n 1
flags           : fpu vme de pse ... aes ... hwp_act_window hwp_epp

这代表使用 aes 是最佳选择～而 CentOS 7 缺省就是使用这个加密机制～因此似乎不是这个问题所致。后来 google 了许多文档，找到数据，不是说网络现出问题，就是 switch 插错，或者是使用 ethtool 设置网络卡速度错误等等，但是我们使用 ethtool 去检查，网卡的信息都是对的！没啥大问题！也就是说，我们一直无法在学期初解决这个从 10G 往 1Gb 发送的慢速问题！

暂时的解决方案

后来学生找到许多短暂的解决方案，大致上就是调降 MTU 到 1300 以下 (注2)，如此一来就可以快速的使用 scp 到正常的速度。不过，因为防火墙系统与学生端系统都需要同步调降 MTU 到 1300 以下，但是上课时，使用的 windows 环境，会主动的将 MTU 调回来，此时，一大堆服务都没有办法顺利的穿透防火墙系统，因此通过网络上课的老师们，大家都苦哈哈！所以，我们只能够在拷贝时将 MTU 调整到 1300 左右，当拷贝完毕后，就得要重新调回 1500 才行！而且网络速度还是时顺时不顺～总之，就是一整个怪异得很！但只能暂时这样处理了！

2、寻找问题的方向

基本上，问题如果定义错误，寻找问题的解决方案时，结果就会出现很大的困扰！

1. 从 scp 着手，结果只能短暂解决问题

如前所述，一开始我们从 scp 的问题着手，去思考解决的方案。会这么做的原因，是因为过去有太多 scp 拷贝速度太低的问题，网络上 google 可以找到一大堆 (注1)～而且，会从 scp 着手，也是因为同学们要将 demo 机器的映像档从防火墙系统上，直接拷贝到学生端电脑，却发现传输速度太慢有关。

因为 scp 有太多奇怪的问题，因此，鸟哥建议学生使用 NFS 搭配 tar 的数据流，直接传输！甚至，通过 nc 直接拷贝这样！不过，最终发现，无论是 scp 还是 NFS 还是 nc 的网络拷贝行为，都是慢到很靠腰！因此，最终还是通过降低 MTU 的方式，以底下的方式直接修改 MTU ，然后在传输完毕后，再次的改回来。

[root@client ~]# ip link show enp8s0
3: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 18:31:bf:cf:c9:90 brd ff:ff:ff:ff:ff:ff

[root@client ~]# ifconfig enp8s0 mtu 1300

[root@client ~]# ip link show enp8s0
3: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1300 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 18:31:bf:cf:c9:90 brd ff:ff:ff:ff:ff:ff

这个解决方案只能短暂的解决问题，因为，如果传输过后，该网卡似乎无法直接将 MTU 设置回 1500，得要将该网卡 down 再 up 才行！这造成许多的困扰～因为，我们通常都是网络连接去控制这些主机的，如果 down 之后无法 up...那就得要亲自跑去主机电脑前面操作系统！另外，如果同时有其他的服务要通过这部机器运作，那些服务 (例如 http 或者是 SNAT 之类的) 就经常无法运作，这造成电脑教室运作的很大的困扰！

2. 网络卡驱动程序，结果无法解决

鸟哥的学生还做了些特别的测试，如同架构图，他们在 Class A 教室中，用户端电脑彼此间使用 scp 传输，是没有问题的！双向速度都可以达到 100Mbytes/s 左右的速度，这是 Giba 的网卡差不多的速度。但是从防火墙系统传输到用户端，就是有问题！而这些网络都是直接串接到同一台 switch 上面的！因此，直觉上，就觉得应该是防火墙主机系统的网络卡驱动程序的问题。

查了一下我们的防火墙系统与 Samba server 使用的网络卡是 Intel 的 X540 AT2 双 10G 芯片组，虽然不是顶级的卡，不过却也确实提供了 10G 的性能～而 CentOS 7 针对这个网络卡提供了 ixgbe 驱动程序，这个驱动程序也是 Intel 官方说的，主要的驱动程序！

[root@server ~]# lspci | grep -i ethernet
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
01:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)

[root@server ~]# lsmod | grep ixgbe
ixgbe                 318969  0
mdio                   14073  1 ixgbe
dca                    15130  1 ixgbe
ptp                    19231  2 ixgbe,e1000e

[root@server ~]# modinfo ixgbe | grep -v '^alias'
filename:       /lib/modules/3.10.0-957.5.1.el7.x86_64/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko.xz
version:        5.1.0-k-rh7.6
license:        GPL
description:    Intel(R) 10 Gigabit PCI Express Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
retpoline:      Y
rhelversion:    7.6
srcversion:     8A6178275DDA252CA16D17C
depends:        mdio,ptp,dca
intree:         Y
vermagic:       3.10.0-957.5.1.el7.x86_64 SMP mod_unload modversions
signer:         CentOS Linux kernel signing key
sig_key:        9D:B7:8A:D7:C3:E3:33:8C:DB:7A:0D:8A:8D:08:F8:80:B4:14:8D:5C
sig_hashalgo:   sha256
parm:           max_vfs:Maximum number of virtual functions to allocate per physical function - default is zero and maximum value is 63 (uint)
parm:           allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599-based adapters (uint)
parm:           debug:Debug level (0=none,...,16=all) (int)

确定了网络卡，而且驱动程序也是最新的！另外，在 parm 的部份，那个是可以额外增加的参数，那部份似乎也没有什么比较特别的地方！所以，网络卡驱动程序的部份，似乎也不是造成这个传输问题的主因啊！

3. 网卡参数的设置

如果上网查找一下 Linux ethtool 以及相关的网络卡参数设置，就会发现有几个常见的网卡参数 (注4)，这些参数据说有可能会影响到网络的性能，大概常见的有：

TCP Segmentation Offload (TSO)：使用网络卡 (NIC) 的硬件功能来处理 TCP 大型封包的分割状态
UDP Fragmentation Offload (UFO)：使用网络卡的硬件功能来处理 UDP 大型数据的数据处理
Generic Segmentation Offload (GSO)：使用 TCP 或 UDP 来发送大型封包，如果网络卡没有即时处理封包分割或拆解时， GSO 会将同样的操作行为直接交给 NIC 的硬件处理。这个动作会延迟封包分割的情况，等到封包可以有空被处理时，才继续下个动作。
Large Receive Offload (LRO)：使用 TCP 协定时，所有进入主机的封包在进入 NIC 时，都会被重新组织，以降低分割的次数为主要思考方向。大型封包可以通过驱动程序或者是 NIC 硬件进行重组。不过 LRO 都会倾向重新组织所有的输入封包，且经常会忽略不同的表头数据与其他封包相关的信息，在 IP foward (就是 NAT 或者是 bridge 的情况) 时，就可能会产生问题。因此，当 IP forward 启动时， LRO 通常都会自动关闭的。
Generic Receive Offload (GRO)：GRO 在进行输入封包的重组时，会比 LRO 严谨，例如 GRO 会检查 MAC 信息，而且也会判断时间戳记是否相同。不过某些情况下，10G 网卡是建议关闭 GRO 的。

查看网络卡目前启动的上述的功能，可以通过 ethtool -k 的参数来处理！例如：

[root@server ~]# ethtool -k enp1s0f0
Features for enp1s0f0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: on [fixed]
        tx-checksum-sctp: on
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: on
        tx-tcp-mangleid-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
busy-poll: off [fixed]
tx-gre-csum-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
rx-gro-hw: off [fixed]
l2-fwd-offload: off
hw-tc-offload: off
rx-udp_tunnel-port-offload: on

上表当中，出现 fixed 表示那是不能变更的参数，其他的若有 off 或 on 的情况，就能够修改。至于修改则使用 ethtool -K 来处理！例如，要将上表中的 gro 关闭时，可以这样做：

[root@server ~]# ethtool -K enp1s0f0 gro off

不过，这几个参数前前后后改了数遍，结果整个性能还是没有什么特别的变化！因此，似乎这个设置值也不是很重要的影响因素。

4. 流量控制 flow control 的影响，应该就是主因了！

因为一直发现到 Gb --> 10G 速度为正常，但是 10G --> Gb 就不正常～鸟哥觉得很奇怪。某天在昆大的操场跑步时，一直思考这个问题主因为何？后来突然发现，无论 10G 还是 Giga，使用的 MTU 单位都是 1500 标准的，这是什么意思呢？这代表，如果 10G 网卡可以使用 1500 的 MTU 传输出 10G 的速度，而 Giga 只能传输 Giga 的速度，这代表 10G 在同样的时间内，可以传输更多的封包数量！

鸟哥突然就想到，giga 的速度比较慢，因此传输给 10G 网卡时，10G 网卡是可以负荷的，因此速度不会有问题！但是如果是 10G 传给 Giga 呢？因为速度太快了，所以 giga 承受不住！因此封包就会遗失，导致 TCP 需要重传，这样速度当然就会下降！而且下降的情况是随机的！突然想到这个可能的原因，因此就朝这个方向去找数据，找到了几个可能的方向 (注5, 6)。

基本上，10G switch 是需要流量控制的！因为跟 10G port 接触的用户端有可能是 giga port，如果两端保持同样的速度，那么 giga port 将会无法负荷！此时，10G switch 内的 flow control 就很重要了！这个 flow control 主要会监测两个 switch port 的速度，当有一端的速度明显的高于另一端时，那么 flow control 就会通知比较快的那一端 (就是 10G port) 传输需要慢一点，才能够跟 giga 接的上！因此，两端的速度才会相同！这样自然就解决上述的问题！

因为一般会购买 10G switch 的环境，大部分都是相同速度的设备串接在一起，亦即不然就是全都为 10G ，不然都是全部 giga，此时，每个 port 的速度都相同，那自然就没有 flow control 的需要！所以，很多的文档都叫你不要启动 flow control。更有趣的是，一般 switch，缺省的情况就是关闭 flow control 的啦！

flow control 是需要 switch 启动的，那么你怎么知道 switch 有没有启动 flow control 了呢？很简单，这样做：

# Intel 的 10G 网卡显示的情况：
[root@server ~]# ethtool enp1s0f0
Settings for enp1s0f0:
        Supported ports: [ TP ]
        Supported link modes:   100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Supported pause frame use: Symmetric  (硬件是否支持)
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
                                1000baseT/Full
                                10000baseT/Full
        Advertised pause frame use: Symmetric (目前的情况)
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

# Broadcom 10G 网卡显示的结果：
[root@server ~]# ethtool em4
Settings for em4:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 19
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Current message level: 0x00000000 (0)

        Link detected: yes

不同网卡展示的结果并不一样，如果是 Intel 的 10G 卡，只会出现『Advertised pause frame use: Symmetric』，如果出现的是『Advertised pause frame use: No』，则代表网卡与 switch 之间不支持 flow control 喔！而如果是 Broadcom 的网卡，基本上则是出现『Link partner advertised pause frame use: Symmetric』，如果出现的是『Link partner advertised pause frame use: No』，也是代表不支持的意思！

一般来说，如果你没有调整过 Linux NIC 的设置，缺省的网卡 flow control 是启动的！因此，如果通过上述指令查看到结果为 No 时，那就代表 10G switch 没有启动 flow control 啰！

在设置完 switch 的 flow control 之后，嘿嘿！ 10G <--> Giga 双向的流量都可以到达 100Mbytes/s (使用 scp 的状态)！这真是太棒了！确定是这玩意儿搞的乌龙啦！哈哈哈！

5. iperf3 软件的使用

通过 scp 虽然可以直接使用到网络的带宽，不过，如果大量传输数据时，例如 10G 的流量情况底下，被读取的文件速度可能会卡住在硬盘 I/O 上面，所以，通过 scp 来直接评判网络状态，似乎是怪怪的。那怎办？没关系，我们可以通过 iperf3 这个软件来处理即可！这个软件可以简单的在网络两端启动，一边启动 server 模式，一边启动 client 模式来访问数据，就能够自动的判断网络带宽了！你可以先前往底下的网站下载：

https://iperf.fr/iperf-download.php

因为鸟哥使用的是 CentOS 7 的版本，因此下载的是 64 比特的版本，就是 3.1.3 那个 RPM 版本，下载后直接使用 yum install ./iperfxxx 安装即可。安装完毕之后，你可以在 Server 端下达这个指令：

# 启动 iperf3 在 Server 模式，系统会主动打开 port 5201 喔！
[root@server ~]# iperf3 -s &
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

# 当然，你得要放行 Port 5201 才行！
[root@server ~]# iptables -I INPUT -s 192.168.32.0/24 -p tcp --dport 5201 -j ACCEPT

接下来在 Client 端，同样的安装好 iperf3 软件，然后这样下达指令：

# 流量从 client 传向 server 的方向：
[root@client ~]# iperf3 -c 192.168.32.254 -t 10 -i 5
Connecting to host 192.168.32.254, port 5201
[  4] local 192.168.32.1 port 46584 connected to 192.168.32.254 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-5.00   sec   568 MBytes   953 Mbits/sec    0    342 KBytes
[  4]   5.00-10.00  sec   566 MBytes   949 Mbits/sec    0    342 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.11 GBytes   951 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.11 GBytes   949 Mbits/sec                  receiver

iperf Done.

3、flow control (switch and NIC)

从前一小节的分析，我们知道 10G switch 以及相关的设备，因为有涉及到不同速度的链接 (10G and Giga)，所以建议所有的设备 (switch and NIC) 都要激活 flow control 才好！

说在前面：使用上的限制

虽然本文确实是在调校 10G 的网络性能，但是并不是适用于所有的环境！基本上，你的 10G switch 环境中，夹杂 10G 与 giga 的网络设备时，同时你的 10G 网卡是具备 mutli queue (多重队列) 才适用于本文的设置喔！不要随便就设置的与鸟哥的环境相同，对于你的网络性能，可能不会有太大的影响。但如果你的环境与鸟哥的相同 (10G 与 giga 设备串接在一起) 时，那对于性能来说，真的有不少帮助喔！

10G switch 的 flow control

因为各家的 switch 控制界面都不一样，例如 cisco 的 switch 还得要使用 telnet 连接才能够设计 flow control 哩！因此，请自行寻找您家使用的 10G switch 操作手册来处理！鸟哥这里只拿我们环境中，使用较为便宜的全 12 port 10G switch： ZyXEL XS1920 这个产品来介绍！顺利的登录这个 switch 之后，选择『 Basic setting 』以及『 Port Setup 』，就会出现如下的画面：

如上图所示，这样所有的 port 就拥有 flow control 的机制了！相当简单！不过，某些特别的 switch 就得要一个一个 port 去设置，稍微复杂些～不过，为了系统性能好！还是调整一下比较妥当！另外，不是调整 10G port 就好喔！举例来说，我们也有 HP 的 HPE 3800-24G-2XG Switch 类似型号，这种类型的 switch 有 2 个 10G port 以及数十个 giga port，所有的 port 都要启动 flow control 才好喔！

Linux NIC 的 flow control 设置

网络卡的设置大部分都与 ethtool 这个指令有关～而其中与流量控制有关的参数，就是 ethtool -a 这个选项了！

[root@server ~]# ethtool -a enp1s0f0
Pause parameters for enp1s0f0:
Autonegotiate:  on
RX:             on
TX:             on

[root@client ~]# ethtool -a enp7s0
Pause parameters for enp7s0:
Autonegotiate:  on
RX:             on
TX:             on

上面的 RX 与 TX 指的是接收与发送的流量控制～基本上，两个都设置比较好！另外，这个项目如果你没有更动过，缺省都是 on 的！如果你看到的是 off 时，有可能是：(1) switch 尚未启动 flow control，(2) 网卡确实忘记启动 flow control。那如果要强制重新启动 flow control 时，可以这样做即可：

[root@client ~]# ethtool -A enp7s0 rx on tx on
rx unmodified, ignoring
tx unmodified, ignoring
no pause parameters changed, aborting

这就代表原本缺省就是 on 的意思啰！如果缺省是 on 却还是显示 off 时，那肯定就是 switch 没有启动 flow control 啰！设置完毕之后，再以底下的方式做个再次确认的动作即可：

[root@client ~]# ethtool  enp7s0
Settings for enp7s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: no

再次确认 Advertised pause frame 使用方式为 Symmetric 就是有 flow control 啰！另外请记得，无论是 10G 还是 giga 的网卡，都要启动 flow control 喔！不然，至少 giga 的网卡 rx (接收) 一定需要 flow control 的啦！

4、其他调校 (ring buffer and queue number)

不知道你跟鸟哥有没有相同的疑问，那就是：『既然 10G 已经是加上 flow control 了，所以传输速度上会与 giga 速度相同，才能让流量稳定。那么问题来了，当有两个 giga 的设备同步访问 10G port 设备时，该 10G 设备能不能个别提供 giga 给两个独立的设备应用？甚至于，能不能独立提供 10 个 giga 的速度给 10 个 giga 的设备使用呢？』，还是最终速度只能剩下 1 个 giga 呢？这是鸟哥一个很大的疑问！

1. 10G 对 10G 的性能测试

首先，通过前一个小节的处理，将 flow control 打开之后，使用缺省的方式 (完全不动 NIC 的参数) 进行两个 10G 网卡间的传输测试，测试的结果有点像底下这样，看起来传输的品质是还不赖的：

[root@client ~]# iperf3 -c 172.31.255.32 -t 10 -i 5
Connecting to host 172.31.255.32, port 5201
[  4] local 172.31.255.102 port 50358 connected to 172.31.255.32 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-5.00   sec  5.45 GBytes  9.36 Gbits/sec  1564   2.87 MBytes
[  4]   5.00-10.00  sec  5.52 GBytes  9.49 Gbits/sec  576   3.03 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  11.0 GBytes  9.42 Gbits/sec  2140             sender
[  4]   0.00-10.00  sec  11.0 GBytes  9.42 Gbits/sec                  receiver

[root@client ~]# iperf3 -c 172.31.255.32 -t 10 -i 5 -R
Connecting to host 172.31.255.32, port 5201
Reverse mode, remote host 172.31.255.32 is sending
[  4] local 172.31.255.102 port 50362 connected to 172.31.255.32 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-5.00   sec  5.52 GBytes  9.49 Gbits/sec
[  4]   5.00-10.00  sec  5.53 GBytes  9.49 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  11.1 GBytes  9.49 Gbits/sec    0             sender
[  4]   0.00-10.00  sec  11.0 GBytes  9.49 Gbits/sec                  receiver

双向传输都可以到差不多 9.4Gbit/s 的传输速度，虽然不到 10G 啦！不过，有 9.5G 左右的传输速度，也算是相当厉害了！而且还是双向哩！所以，同时上传下载，或许能够达到 20G 左右喔！因此，10G switch 两侧同样是 10G NIC 时，启动 10G switch 的 flow control，对于传输的带宽来说，应该影响不很大，速度是正常没问题的！

2. 10G 对 10 个 giga 的性能测试

接下来就是我们最担心的部份，那么有 2 port 10G + 24 port giga 的 switch 性能到底如何？就是本文一开始的那张图里面的 Class A 啦！防火墙系统使用 10G NIC 并且安插在 10G switch port 上面，其他用户端电脑则直接安插在 giga port 上面，使用的也是一般的 giga NIC 而已。

iperf3 的 Server <--> Client 连接信道中，只能单独一个连接，无法两条连接同时使用一个 port number。所以，如果我们想要测试 10 个 giga 设备的话，不能只使用一个端口口喔！基本上，测试环境大概是这样：

Server IP 192.168.32.254，使用 10G NIC 插在 10G port 上
Clients IP 192.168.32.1~192.168.32.10 这十台，使用 giga NIC 插在 giga port 上
Server 已经将 ssh public key 安装在那 10 台系统中了，所以可以直接通过 root 去运行指令。
Server 预计激活 5201 ~ 5210 的 10 个端口口让用户端分别连接。

在这样的情况下，Server 可以这样运行 iperf3 喔：

[root@server ~]# cat start_iperf3.sh
#!/bin/bash

for i in $( seq 1 10 )
do
        port=$(( 5200 + ${i} ))
        iperf3 -s -p ${port} &
done

[root@server ~]# source start_iperf3.sh

如果要同步运行 client 下达 iperf3 有点伤脑筋，因此，通过脚本直接运行是最简单的了！可以这样直接运行看看：

[root@server ~]# cat client_to_server.sh
#!/bin/bash

for i in $(seq 1 10)
do
         port=$(( 5200 + ${i} ))
         usleep 100000; ssh -f 192.168.32.${i} " iperf3 -c 192.168.32.254 -p ${port}  -t 10 -i 5 -R -f m| grep sender   &"
        #usleep 100000; ssh -f 192.168.32.${i} " iperf3 -c 192.168.32.254 -p ${port}  -t 10 -i 5    -f m| grep receiver &"
done

[root@server ~]# sh client_to_server.sh

鸟哥测试过，如果没有加上 usleep 时，因为每个 client 都同时跑去跟 server 要数据，此时可能会造成网络稍微拥塞，因此性能一直不太好。所以，通过每 0.1 秒才运行一个连接，性能会稍微好些。至于两行测试，一个是运行 10 个 client 发送数据给 server，一个是运行 server 发送 10 个数据给 client，两者是有差异的！结果分析是这样的：

当运行 10 个 Client 发送数据给 server 时，以 Server 10G NIC 的角色来看，此时是『接收 (receiver) 』的行为，无论怎么运行脚本 (有没有加上 usleep 都无关)，整体的带宽都可以到达 9.5G 以上！是接近到 10G 的性能！所以， 10G NIC 在接收 (rx) 的情境下，性能完全没有任何影响！相当良好！
当运行 10G 网卡发送 10 个数据给 client 时，其性能很奇特！有时候仅有 4, 5G 而已，有时候可以到接近 8G，有时候只能是 3G，性能变化相当大！此外，不论怎么运行，全部加总的带宽数据结果，大多是 0.95G 的倍数！也就是，如果是最佳的 8G 带宽，则有 4 个 client 会明显的低于 950Mbit/s，但是这 4 个加总则大约是 2*950Mbit/s 的带宽！另外 6 个则是完整的 950Mbit/s 的带宽使用！

以 10G 网卡的角度来看，接收数据是没有问题 (rx)，但是发送数据则会有很大的差异产生！而且发送数据 (tx) 总和会是 950Mbit/s 的倍数！这个情况相当特别！有点意思！无论如何，既然接收可以到达接近 10G 的性能，没道理发送 (tx) 会这么糟糕！所以，我们开始查找数据来进行性能调校！

3. 系统的整体优化 tuned 服务

早期，我们为了加强网络与磁盘性能，得要自己调整 /etc/sysctl.conf 里面的相关数据，包括 TCP 封包的缓冲内存使用量、最大与优化过的缓冲内存信息等，搞到有点民不聊生...经过网络前辈们的努力，其实大家调整的方向都差不多，因此，就有个可以自动调整相关封包与磁盘 I/O 数据的服务出现！那就是 tuned 这个服务了！

如果是 CentOS 7 的环境，那么大概这个服务在你安装好之后就启动了，如果是 CentOS 6 的环境，那就得要自己去安装启动才行。另外，tuned 服务提供了 tuned-adm 这个指令功能，可以让你快速的处理不同的使用情境 (注 7)。假设你已经安装了 tuned ，那么可以这样的查阅你目前的性能调整情境：

[root@server ~]# tuned-adm list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optimize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: balanced

缺省会是平衡模式，如果你想要使用到网络优化，就可以使用底下的方式来处理：

[root@server ~]# tuned-adm profile throughput-performance
[root@server ~]# tuned-adm verify
Verfication succeeded, current system settings match the preset profile.
See tuned log file ('/var/log/tuned/tuned.log') for details.

很神奇的是，CentOS 7 的 tuned-adm 还可以告诉你哪边的设置不太对劲～你可以持续手动去调整哩！那如果以鸟哥的环境来看，我们的 Class A 教室内那几部 client 端的电脑，其实是要跑虚拟机的，那你可以在那几部机器上面使用底下的数据来修订：

[root@client ~]# tuned-adm profile virtual-host

其他的就请自行测试啰！不过，即使这样已经调整好整个系统的优化，不过对于 10G 网卡来说，其实 10G 发送到 10 个 giga 的带宽，还是没有办法达到很好的效果，依旧是与之前的状态一样，就是断断续续的，时好时坏～虽然大多数时间的测试，都可以超过 6G 以上，不过，能够到达 8G 以上的次数还是很少！这实在是相当伤脑筋！

4. 10G NIC 的网卡特征 (lro, gro)

根据 Intel 网卡 driver 的说法 (注 3)，那个 lro 以及 gro 在 router 与 bridge 有关的环境下，最好关闭比较妥当！而我们的 10G NIC 所在的环境，就是有防火墙的 SNAT 与 DNAT 的设置情境下，做着路由相关的工作，因此确实将这两个网络卡特征关闭比较好！至于用户端的环境，就不需要进行这个动作啰！只针对 10G NIC 才需要进行！

[root@server ~]# ethtool -k enp1s0f0 | grep -i receive
generic-receive-offload: on  <==这个
large-receive-offload: off   <==这个
receive-hashing: on

[root@server ~]# ethtool -K enp1s0f0 lro off gro off

[root@server ~]# ethtool -k enp1s0f0 | grep -i receive
generic-receive-offload: off <==这个需要变化！
large-receive-offload: off
receive-hashing: on

这样就做好了网卡的特征规范～只是，依旧，对于 10G NIC 发送 10 个 giga 到 client 去的动作，依旧没有什么特别的帮助！

5. 10G NIC 的 ring buffer 设置

在追踪一阵子的 google 讨论之后，如注 8 所找到的相关数据，发现网络卡还有个 ring 的参数可以修改！原本系统缺省的是 256 而已，不过硬件支持到 4096！不过，这个硬件支持度在各家网卡都不太一样～所以，我们得要先来测试一下，确定了正确的数据，再来修改。相关的观察与设置可以使用 ethtool 来处理。同样的，只需要在 10G NIC 端进行即可：

# 先观察一下有多少 ring 的参数可以用：
[root@server ~]# ethtool -g enp1s0f0
Ring parameters for enp1s0f0:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256

# 将设置值修改到最大！
[root@server ~]# ethtool -G enp1s0f0 rx 4096 tx 4096

这样就设置完毕了！不过，依旧，没有办法处理好相关的 10G NIC 发送 10 个 giga 的带宽使用率！

6. 10G NIC 的 queue number 设置

在查找 10G NIC 使用 Intel 的厂牌时，发现到注 9 这篇文章，该文章第六页最左侧最下方的几个圆点清单项目说明中，谈到一个相当有趣的特色，他提到你要优化 10G 网卡时，最好需要进行：

Turn ON Receive (Rx) Multi-Queue (MQ) support (enabled by default in RHEL); Transmit (Tx) is currently limited to one queue in RHEL, SLES 11rC supports MQ Tx

意思是说，RHEL (其实就是 CentOS) 的接收缺省使用多重队列，而发送的情况下，缺省一个发送只会使用到一个队列的意思！这个队列 (queue) 引起鸟哥很大的注意！这是因为原本网络卡上面使用 ip link show 时，就会显示网卡有个队列长度，依据网络上面的许多文档，这个队列长度会影响到数据的传输！因此对于 10G NIC 来说，最好加大到 10000 比较好！设置的方式通常是：

[root@server ~]# ifconfig enp1s0f0 txqueuelen 10000
[root@server ~]# ip link show enp1s0f0
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 10000
    link/ether a0:36:9f:3e:c4:38 brd ff:ff:ff:ff:ff:ff

不过这个队列修改很早之前就设计了！因此，没有影响啊！但是，仔细查看上述的输出！

[root@server ~]# ip link show enp1s0f0
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 10000
    link/ether a0:36:9f:3e:c4:38 brd ff:ff:ff:ff:ff:ff

果然，缺省的情况下，CentOS 7 针对 10G 网卡，已经缺省激活了 mq 这个 muilti queues 的功能了！也就是说，这似乎已经是正确的启动了相关的支持！那么，什么是队列呢？就鸟哥的认知来说，网络卡队列的功能大概是这样的：

当有发送的需求时，一个进程的发送会占用一个 queue，根据上述 Intel 文档的说明，该发送进程只会使用一个队列，即使该队列已经满了，该进程也不会占用其他的队列。
因为需要与 Giga 速度同步，因此，这个队列的传输极限速度，就是到达 giga 而已。
如果该队列主要是传输到 10G 的另一个网络媒体时，则该队列的极限速度就会达到 10G ！

这样说起来，那么 10G NIC 的队列可能会有多个才对！不然，与 giga 网卡接触时，该队列只能提供 1Giga 的速度，那就不可能提供超过 1G 的流量啊！所以，鸟哥就朝着队列的个数去找～最终找到 ethtool 里面有个 -l 的参数可以查阅队列个数喔！

[root@server ~]# ethtool -l enp1s0f0
Channel parameters for enp1s0f0:
Pre-set maximums:
RX:             0
TX:             0
Other:          1
Combined:       63
Current hardware settings:
RX:             0
TX:             0
Other:          1
Combined:       8

咦！硬件提供了 63 个可用的队列，但是系统仅取用 8 个队列而已！怪不得系统最大只能抓到 8G 的流量，而且老是取用了整数 giga 左右的性能！如果 10 个用户端的发送，结果系统误判使用了 6 个队列 (有两个队列没被使用) 时，则最大当然就是使用到 6G 的性能！

这时鸟哥也才知道，为什么通过 iperf3 去测试发送 10 个数据给 10 个用户端时，有的会跑完整的 1G 速度，有的则加总才是 1G 的速度！原来单独 1G 的速度，可能被单独一个用户端取用，也可能被多个用户端共用！而在极端的环境下，每个队列都被用到，就有 8G 的性能，如果只有 5 个队列被使用，那总量只能达到 5G 啰！原来如此！了解了！

既然是这样，那么将所有的 63 个队列通通激活，不就变得比较好！？OK！我们来调整一下队列个数吧！

[root@server ~]# ethtool -L enp1s0f0 combined 63

这样就将队列由 8 个转成 63 个了！此时如果重复使用 iperf3 的用户端软件去运行测试，就会发现，确实，流量使用会比较广，大部分的测试都可以到达 7G 以上，比以前从 4, 5G 到 8G 的速度来说，好上许多！而且，在极端好运的情况下，每个用户端都可以取得 1G 的带宽(10 次测试会出现个 2, 3 次)。

不过，大部分的情况 (60% 左右)，带宽大致都使用到 7G 左右，也就是说，有 2 ~ 4 个用户端，会共用 2G 左右的带宽，这样虽然已经算很不错，不过，就是损失了 20% 的性能，让鸟哥觉得很泄气！

7. 10G NIC 的 multiq 队列参数与 filter 分流功能设置

因为我们的环境 (最开始图标中的 Class A) 是很固定的，教室内的电脑数量、电脑 IP 与电脑的网络连接到 switch 的线路都是固定的，而且现在也知道 intel 的 10G NIC 拥有 63 个队列，那么能不能进行分流？意思是：

queue 1 --> client 1
queue 2 --> client 2
queue 3 --> client 3
queue .. --> client ..

如此一来，不就可以肯定让每个队列服务固定的用户，每个用户就可以拥有一条 10G 提供的专属信道，那我们知道每条队列都是 1G！哇！如此岂不是可以得到完整的 10G 了呢？依据这个想法，于是鸟哥慢慢搜索数据，以 multi queue 去查找，结果找到了一堆文档注 10，里面最重要的就是 linux kernel 提供的那篇 multi queue 的指引了！

tc 这个指令可以找出队列的机制以及是否设置分流的行为，缺省的情况下，运行 tc qdisc show 可以得到如下的结果：

[root@server ~]# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc pfifo_fast 0: dev eno1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc mq 0: dev enp1s0f0 root
qdisc pfifo_fast 0: dev enp1s0f0 parent :8 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :7 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :6 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :5 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :4 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :3 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f0 parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc mq 0: dev enp1s0f1 root
qdisc pfifo_fast 0: dev enp1s0f1 parent :8 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :7 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :6 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :5 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :4 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :3 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0f1 parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

看起来 enp1s0f0 这个主要的网卡确实就是使用 mq 的机制～但是，这个 mq 机制是系统自己处理分流的动作，而且在缺省的情况下，提供了原本的 8 个队列信息，虽然私底下确实可以提供所有 63 个队列...不过这个 mq 没办法让我们手动处理 IP 对应的方流喔！那怎办？通过刚刚 Linux kernel 的文档，我们可以使用一个名为 multiq 的队列机制来处理！不过你得要注意：

鸟哥多次测试的经验中，让系统自己设置队列分流的情况下，性能最佳的就是 mq 这个机制！在文末的参考文献中，也提到 mq 确实具有最佳的性能与带宽使用率！所以，如果你不能确定你的环境当中的每个用户，或者是你的用户个数超过你的队列数，建议不要使用 multiq！否则性能反而会下降 10% 左右喔！

反过来说，如果你的环境跟鸟哥的类似，就是中间通过 10G, 1G 同时存在的 swtich 环境时，那么使用 multiq 来分流，可能是最佳的方案！接下来，请这样做：

[root@server ~]# tc qdisc del dev enp1s0f0 root
[root@server ~]# tc qdisc add dev enp1s0f0 root handle 1: multiq
[root@server ~]# tc qdisc show dev enp1s0f0
qdisc multiq 1: root refcnt 65 bands 63/64   <==确实由 mq 更改为 multiq 啰！

# 将 queue 1 单独分给 192.168.32.1 
[root@server ~]# tc filter add dev enp1s0f0 parent 1: protocol ip prio 1 u32 match ip dst 192.168.32.1 action skbedit queue_mapping 1
[root@server ~]# tc filter show dev enp1s0f0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? not_in_hw
  match c0a82001/ffffffff at 16
        action order 1:  skbedit queue_mapping 1 pipe
         index 1 ref 1 bind 1

接下来，依序将 192.168.32.2 ~ 192.168.32.18 分别带入 queue 2 ~ queue 18 ，就结束了！自此之后，每次侦测流量时，每个用户端几乎具有完整的 1G 流量！虽然与 mq 相比，单独的用户都可以使用到接近 950Mbit/s 的带宽， multiq 最大则约到达 930Mbit/s 而已，性能降低大约 2%~3% 左右，但是如果考量到总体的带宽使用率，在系统相当繁忙的情况下，整个总量反而发挥的比较好！因此，使用 multiq 所损耗的这 3% 传输性能，是在鸟哥可以接受的情况下。

另外，在鸟哥测试全部 18 台主机的环境下，multiq 对于带宽的平均分配也比较好喔！毕竟每个用户端都有独立的队列支持，因此全部的用户端就可以平均的去抢那 10G 的带宽，如果是 mq 的情况下，那就看运气了！运气好的自己使用独立的队列，那速度就快上许多，如果跟人家共享队列的，例如假设有 3 个人共用一个队列，那么这三个人就得要慢慢的传输了！即使隔壁的单独使用队列的朋友已经下载完毕了，这三个人在系统的 mq 队列设置环境下，依旧无法挪动到空的队列，就得要三个人共用 1G 哩！这实在是不合理！虽然 mq 是单独队列传输最快的...

8. 严重问题

在完成上面的测试之后，就将设置值写入 /etc/rc.d/rc.local 当中，以为这样就搞定所有的事情了！没想到稍晚再次测试流量带宽，却发现 10 台流量全部变成 100Mbps 左右，足足少了 10 倍！鸟哥以为同时间有其他伙伴在测试，但是使用 tcpdump 去检查，没有发现大量封包喔！之后开始一台一台检查，却发现 18 台当中，有一台因为网络卡速度降为 100Mbps！就因为这台降为 100Mbps，导致批量处理时，所有的封包都变成 100Mbps 了！

分析为何网络卡性能会自动降为 100Mbps 呢？这是由于 Class A 的线路比较老旧，尤其从 patch panel 连接到 switch port 的短跳线经常拔插，导致水晶头有点脱落。因此，就造成偶而某几台网络的性能会很烂！

以前使用的 mq 因为他的队列使用 first in first out 的功能，并不会去分析封包，因此传输的速度超快！而且每个队列都是分开独立，因此，有一台降速时，不会影响其他台的队列使用。现在使用的 multiq 就不是这样喔！因为 multiq 会去分析封包，然后将不同的封包带入不同的队列。因此，若有不同速度的传输，那该网卡就可能会使用最低速的传输，作为整体的传输动作！所以，只要使用到该台 100Mbps 的系统，整个网卡的性能就被卡死了...

虽然要使用 100Mbps 设备的几率几乎是 0，但是像鸟哥这次遇到的状态，是因为网络线材品质不良所致！这种状况可就经常发生了！因此，是否要使用 multiq ？还是乖一点，单纯使用系统缺省的 mq 即可？这可真是见仁见智！总之，先将可能发生的问题告知您，让大家了解一下如果遇到这个状况，最可能的问题为何较佳！

不过，测试之后又出现了解决方案～只要设置 filter 时，指定不同的 prio 号码即可！亦即底下的地方都需要修改！

[root@server ~]# tc filter add dev enp1s0f0 parent 1: protocol ip prio 1 u32 match ip dst 192.168.32.1 action skbedit queue_mapping 1
[root@server ~]# tc filter add dev enp1s0f0 parent 1: protocol ip prio 2 u32 match ip dst 192.168.32.2 action skbedit queue_mapping 2

似乎相同的 prio 会依据相同的速度来分配到不同的队列的样子～所以分开似乎就没问题了！

5、结语与参考数据

在大约 2017 年中就有发现 10G NIC --> 1G NIC 的 scp 传输有点慢，大概只到 40Mbyte/s 的带宽使用率，不过因为以前 ssh 传输的速度就比较慢，因此鸟哥也不以为意。

就是要解决自身的问题啊！

直到 2019 年的农历年前一周，为了要通过 10G 传输数据到鸟哥的 cluster 去，却发现传输时，scp 的流量仅有 5Mbytes/s 而已！比起 40Mbytes/s 的情况还要严重很多！因为鸟哥办公室使用的是 10G NIC，Cluster 内部使用的也是 10G NIC，但是 Cluster 外部使用的就是 1G NIC！这是因为 cluster 内部需要的速度比较大，而且 cluster 通常是不跟外部连接的，所以跟外部连接仅有 1G NIC 来提供基本的传输而已。

进一步使用 iperf3 分析这个情况，才发现 1G --> 10G 流量没问题，产生问题的是 10G --> 1G 的情境！而且 10G --> 1G 的流量很不稳定，有时候运气好可以到达 600Mbyte/s，情况不好时，甚至连 100Mbytes/s 也没办法到达！这才让鸟哥开始怀疑，我们的 10G 优化，是否反而是造成整体性能的低落！所以就有这篇数据的产生！

最重要的解决方案

整份文档可以参考的项目不少，但是，影响到 10G 环境中的性能最重大的参数，大概就是两个：

10G switch 与 10G NIC 的 flow control 一定要激活！
增加 10G NIC 的队列个数到硬件最大支持个数
如果有固定的用户端 IP 环境，将 queue 的机制改成 multiq ，并且加上分流 (filter) 处置！

经过这几个动作的修改，整个电脑教室的性能得以得到完整的发挥！而且每个用户端几乎具有各自的 1G queue 支持，而且带宽分布相对的公平！真的不枉费 2019 年春节假期的努力啊！

累死人！

其实故事没有这么简单...鸟哥测试了好几种 qdisc 机制，每种设置完毕就得要重新测试！虽然为了加速，每次测试只有 1 分钟左右，不过，鸟哥可以用来测试的时间也不多啊！过年期间许多拜年与家庭日总是得要顾及的～结果几乎每天晚上都搞到 2, 3 点才去睡！哈哈哈！

参考数据：

底下的数据是鸟哥觉得比较重要的，看看大家能不能从中找到更多的好方法！

注 1：Improving ssh/scp Performance by Choosing Suitable Ciphers
注 2：Why does SCP hang on copying files larger than 1405 bytes?
注 3：Supermicro: Linux* Base Driver for 10 Gigabit Intel® Ethernet Network Connection
注 4：Red Hat: NIC offloads
注 5：AIXpert Blog: 10Gbit Ethernet, bad assumption and Best Practice
注 6：NetAPP vs VMWare Flow control dilemma
注 7：Red Hat Enterprise Linux: tuned
注 8：与 NIC 参数调整有关的几篇讨论：
注 9：Intel: Maximizing File Transfer Performance Using 10Gb Ethernet and Virtualization
注 10：与 NIC 队列 (queue) 有关的几篇文章：

修改历史：

2019/02/10 以来统计人数
计数器