文章总结： 文档深入解析openEuler系统的网络核心诊断方法，涵盖/sys/class/net目录下网卡身份、链路状态、电源管理及统计计数器的关键参数。重点介绍了通过carrier与operstate判断物理链路、利用statistics排查丢包与硬件故障、以及配置RPS实现多核负载均衡的实战技巧。内容结合原理分析与Shell脚本示例，提供了快速定位网络故障与性能调优的具体方案，具有极高的实操价值。 综合评分： 92 文章分类： 实战经验,安全运营,解决方案

---

openEuler 网络核心诊断指南

原创

刘军军 刘军军

运维星火燎原

2026年3月4日 00:00 天津

一、/sys/class/net/ens33/网络接口信息接口。

1.核心身份与地址信息

• address: MAC 地址。网卡的物理地址（如 00:0c:29:xx:xx:xx）。

• ifindex: 接口索引号。内核分配给该网卡的唯一数字 ID（例如 2），比名字更稳定，常用于底层编程。

• iflink: 通常与 ifindex 相同。如果这是一个虚拟设备（如 VLAN 或桥接），它可能指向底层物理设备的索引。

• addr_len: 地址长度。以太网通常是 6 (字节)。

• broadcast: 广播地址。通常是 MAC 地址的最后一位变为 ff (如 ff:ff:ff:ff:ff:ff)。

• addr_assign_type: MAC 地址的分配类型。

• 0: 永久地址（烧录在硬件里）。

• 1: 随机生成（常见于容器或隐私保护模式）。

• 2: 由管理员设置。

• name_assign_type: 网卡名称（ens33）是如何分配的（是内核自动起的，还是用户固定的）。

2.连接状态与物理链路 (非常重要)

• operstate: 操作状态（最常用）。显示网卡当前的逻辑状态。

• up: 接口已启用且链路正常。

• down: 接口被禁用或链路断开。

• unknown: 状态未知（常见于某些虚拟化环境）。

• carrier: 物理载波信号。

• 1: 检测到物理信号（网线插好了，对端设备也开着）。

• 0: 无物理信号（网线没插，或对端关机）。

• speed: 当前协商速率。如 1000 (代表 1000Mbps/1Gbps)。如果是 -1 表示无法获取（常见于 WiFi 或某些虚拟网卡）。

• duplex: 双工模式。

• full: 全双工（同时收发）。

• half: 半双工。

• unknown: 未知。

• dormant: 休眠状态。1 表示接口处于某种等待状态（较少见，通常用于特殊协议）。

• carrier_changes: 记录链路状态变化（插拔网线）的次数。

• carrier_up_count / carrier_down_count: 链路向上/向下的累计次数。用于排查网络是否频繁抖动。

3.配置与控制 (可读写)

• mtu: 最大传输单元。默认通常是 1500 字节。你可以写入新值来修改它（例如改为 9000 开启巨型帧）：

echo9000 > mtu

• flags: 接口标志位的十六进制表示。包含是否启动 (UP)、是否广播 (BROADCAST)、是否多播 (MULTICAST) 等底层标志。
• tx_queue_len: 发送队列长度。默认通常是 1000。在高延迟网络中，增加此值可能有助于提高吞吐量。
• ifalias: 接口的别名。你可以写入一个描述性字符串（如 “Connection to DB Server”），方便管理，不影响功能。
• gro_flush_timeout & napi_defer_hard_irqs: 高级网络性能调优参数，用于控制中断合并和数据包处理延迟，通常不需要手动修改，除非进行极致的网络优化。
• threaded: 是否启用网络接收处理的线程化模式（用于多核负载均衡）。
• proto_down: 允许用户空间协议（如 BGP 守护进程）标记接口为“协议_DOWN”，即使物理链路是通的。

4.统计信息目录

• statistics/ (目录): 里面包含了一堆计数器文件，是网络监控的核心数据源。

• rx_bytes / tx_bytes: 接收/发送的总字节数（计算流量用）。

• rx_packets / tx_packets: 接收/发送的数据包数量。

• rx_errors / tx_errors: 错误包数量（如果很高，说明网线或驱动有问题）。

• rx_dropped / tx_dropped: 丢弃的包数量（如果很高，说明 CPU 处理不过来或缓冲区满了）。

5.硬件与电源关联

• device -> ../../../0000:02:01.0: 这是一个符号链接，指向该网卡对应的 PCI 设备路径。你可以通过这个路径找到该网卡的更多硬件详情（如驱动程序名称）。
• subsystem: 指向网络设备子系统的链接。
• power/ (目录): 包含该网卡的电源管理文件（即你之前问到的 autosuspend_delay_ms 等），用于控制网卡是否可以在空闲时休眠。
• phys_port_id / phys_switch_id: 如果网卡支持 SR-IOV 或连接到物理交换机，这里会显示物理端口或交换机的 ID，用于识别虚拟功能（VF）对应的物理位置。

6.其他

• type: 设备类型代码。1 代表以太网 (Ethernet)。
• netdev_group: 网络设备组 ID，用于将多个接口逻辑分组。
• uevent: 包含该设备的环境变量信息，主要用于 udev 规则匹配。
• testing: 通常用于内核开发测试，生产环境忽略。

---

实战场景举例

场景 1：快速检查网线是否插好

不用敲 ip addr，直接看这两个文件最快：

cat carrier      # 输出 1 表示插好了，0 表示没插好
cat operstate    # 输出 up 表示逻辑上也通了

场景 2：查看网卡是不是千兆

cat speed        # 输出 1000 表示千兆，100 表示百兆
cat duplex       # 确认是全双工 (full)

场景 3：排查网络丢包

如果网络卡慢，看看是不是丢包严重：

cat statistics/rx_dropped
cat statistics/tx_errors
# 如果数字在不断快速增加，说明有硬件故障或系统负载过高

场景 4：临时修改 MTU (例如为了测试巨型帧)

# 注意：需要 root 权限，且重启后失效
echo 9000 > mtu

二、/sys/class/net/ens33/powerLinux 内核 运行时电源管理 (Runtime Power Management, Runtime PM) 的核心接口。

1. control (控制策略)

• 权限: 可读写 (-rw-r–r–)

• 作用: 决定该设备是否允许被内核自动挂起。

• 可选值:

• on: 强制开启。设备将始终保持活跃状态，即使它空闲也不会自动休眠。通常用于解决设备因休眠导致的断连或故障。

• auto: 自动管理（默认推荐）。内核驱动程序会根据设备的使用情况，自动判断何时挂起设备以省电。

• 常用操作:

# 如果某个USB设备经常莫名其妙断开，可以强制它不休眠
echoon > control

2. autosuspend_delay_ms (休眠延迟时间)

• 权限: 可读写 (-rw-r–r–)

• 作用: 设置设备在检测到“空闲”状态后，等待多少毫秒才执行自动挂起。

• 单位: 毫秒 (ms)。

• 常见值:

• 1000: 空闲 1 秒后挂起。

• 5000: 空闲 5 秒后挂起。

• -1: 永不自动挂起（即使 control 设为 auto）。

• 常用操作:

# 设置设备空闲 2 秒 (2000毫秒) 后进入休眠
echo 2000 > autosuspend_delay_ms

3. runtime_status (当前状态)

• 权限: 只读 (-r–r–r–)

• 作用: 查看设备当前的电源运行状态。

• 常见返回值:

• active: 设备正在正常工作（活跃）。

• suspended: 设备已处于低功耗休眠状态。

• suspending: 正在进入休眠的过程中。

• resuming: 正在从休眠中唤醒。

• error: 电源管理过程中发生错误。

4. runtime_active_time (活跃时间统计)

• 权限: 只读 (-r–r–r–)
• 作用: 记录设备自启动以来，处于 active (活跃) 状态的总时长。
• 单位: 毫秒 (ms)。
• 用途: 用于分析设备的使用频率和功耗占比。

5. runtime_suspended_time (休眠时间统计)

• 权限: 只读 (-r–r–r–)
• 作用: 记录设备自启动以来，处于 suspended (休眠) 状态的总时长。
• 单位: 毫秒 (ms)。
• 用途: 配合 runtime_active_time 评估电源管理策略是否生效。如果这个数值很大，说明设备大部分时间都在省电。

---

场景一：排查设备故障（如网卡或存储掉线）

如果你发现某个硬件（例如 USB 加密狗、特定的网卡）偶尔无响应，可能是内核为了省电把它“关”了，但驱动没能及时唤醒它。解决方法：

# 进入该设备的 power 目录
cd /sys/devices/.../power/
# 禁止自动休眠
echo on > control

场景二：极致节能优化

如果你希望服务器在非高峰期尽可能省电，可以检查所有设备的 control 是否为 auto，并缩短延迟时间。

# 设置更激进的休眠策略（空闲 0.5 秒即休眠）
echo 500 > autosuspend_delay_ms
echo auto > control

场景三：监控设备活跃度

你可以写一个简单的脚本监控 runtime_status，或者计算休眠占比，来评估哪些硬件是“耗电大户”。

# 查看当前状态
cat runtime_status
# 查看统计时间
echo"活跃时间: $(cat runtime_active_time) ms"
echo"休眠时间: $(cat runtime_suspended_time) ms"

注意事项

1. 临时生效: 直接 echo 修改这些文件通常是临时的。重启后，系统可能会根据 udev 规则或驱动默认设置重置它们。若要永久生效，通常需要配置 udev 规则文件（位于 /etc/udev/rules.d/）。
2. 驱动支持: 并非所有硬件驱动都完美支持 Runtime PM。如果修改后导致设备异常，请改回 on。
3. Root 权限: 修改这些文件需要 root 权限（你已经是 root 用户，所以可以直接操作）。

三、/sys/class/net/ens33/statistics网络接口统计计数器

openEuler（以及所有 Linux 系统）中看到的 /sys/class/net/<网卡名>/statistics/ 目录下的这些文件，是网络接口统计计数器。

它们记录了自网卡启动（或计数器重置）以来，该网卡接收（RX）和发送（TX）数据的详细统计数据。这些是网络监控工具（如 iftop, nload, sar）和故障排查的核心数据源。

我们将这些文件分为三大类进行解读：基础流量统计、接收端（RX）错误统计、发送端（TX）错误统计。

---

1.基础流量统计 (最常用)

这些文件用于计算带宽使用率、数据包吞吐量。

| | | | | — | — | — | | 文件名 | 含义 | 作用与解读 | | rx_bytes | 接收字节数 | 网卡总共接收了多少字节的数据。计算下载带宽的核心依据。 | | tx_bytes | 发送字节数 | 网卡总共发送了多少字节的数据。计算上传带宽的核心依据。 | | rx_packets | 接收数据包数 | 成功接收的数据包总数。 | | tx_packets | 发送数据包数 | 成功发送的数据包总数。 | | multicast | 多播包数 | 接收到的多播数据包数量（常用于视频流、集群心跳等）。 | | collisions | 冲突数 | 以太网帧冲突次数。在现代全双工交换机网络中，此值应始终为 0。如果不为 0，说明网络硬件或双工模式配置有严重问题。 | | rx_compressed / tx_compressed | 压缩包数 | 硬件压缩的数据包数。现代网卡通常不支持硬件压缩，此值通常为 0。 |

小技巧：要查看实时网速，可以写个脚本每秒读取一次 rx_bytes 并计算差值。

---

2.接收端错误统计 (RX Errors)

如果服务器**“收不到数据”、“网络卡顿”或“丢包”**，重点检查这里。

| | | | | — | — | — | | 文件名 | 含义 | 故障原因分析 | | rx_errors | 接收错误总数 | 所有接收错误的总和（包含下面具体的错误类型）。 | | rx_dropped | 接收丢弃数 | 非常重要！ 表示内核收到了包，但因为缓冲区满、CPU 处理不过来或防火墙规则而丢弃了。如果此值持续增加，说明服务器负载过高或网络突发流量太大。 | | rx_crc_errors | CRC 校验错误 | 数据帧在传输过程中损坏（校验和不匹配）。通常由劣质网线、电磁干扰或网卡/交换机端口硬件故障引起。 | | rx_fifo_errors | FIFO 溢出错误 | 网卡硬件接收缓冲区（FIFO）满了，新来的数据没地方放被丢弃。说明网卡处理速度跟不上线路速度，或中断响应太慢。 | | rx_frame_errors | 帧格式错误 | 接收到的数据包长度不是整数字节，或帧对齐错误。通常也是物理层故障（网线、端口）。 | | rx_length_errors | 长度错误 | 数据包长度不符合协议规定（太长或太短）。 | | rx_missed_errors | 错过错误 | 通常与 FIFO 溢出相关，表示因硬件资源不足而错过的包。 | | rx_over_errors | 过载错误 | 类似于 FIFO 错误，表示接收器过载。 | | rx_nohandler | 无处理器丢弃 | 数据包被接收了，但没有对应的协议处理器（例如收到了一个本机不支持的协议包）。通常在关闭网卡时会出现。 |

---

3.发送端错误统计 (TX Errors)

如果服务器**“发不出数据”、“连接超时”**，重点检查这里。

| | | | | — | — | — | | 文件名 | 含义 | 故障原因分析 | | rx_errors | 接收错误总数 | 所有接收错误的总和（包含下面具体的错误类型）。 | | rx_dropped | 接收丢弃数 | 非常重要！ 表示内核收到了包，但因为缓冲区满、CPU 处理不过来或防火墙规则而丢弃了。如果此值持续增加，说明服务器负载过高或网络突发流量太大。 | | rx_crc_errors | CRC 校验错误 | 数据帧在传输过程中损坏（校验和不匹配）。通常由劣质网线、电磁干扰或网卡/交换机端口硬件故障引起。 | | rx_fifo_errors | FIFO 溢出错误 | 网卡硬件接收缓冲区（FIFO）满了，新来的数据没地方放被丢弃。说明网卡处理速度跟不上线路速度，或中断响应太慢。 | | rx_frame_errors | 帧格式错误 | 接收到的数据包长度不是整数字节，或帧对齐错误。通常也是物理层故障（网线、端口）。 | | rx_length_errors | 长度错误 | 数据包长度不符合协议规定（太长或太短）。 | | rx_missed_errors | 错过错误 | 通常与 FIFO 溢出相关，表示因硬件资源不足而错过的包。 | | rx_over_errors | 过载错误 | 类似于 FIFO 错误，表示接收器过载。 | | rx_nohandler | 无处理器丢弃 | 数据包被接收了，但没有对应的协议处理器（例如收到了一个本机不支持的协议包）。通常在关闭网卡时会出现。 |

---

实战：如何利用这些文件排查故障？

场景 1：服务器网络很卡，怀疑丢包

执行以下命令观察 rx_dropped 和 tx_dropped 是否在快速增加：

watch -n 1'cat /sys/class/net/ens33/statistics/rx_dropped; cat /sys/class/net/ens33/statistics/tx_dropped'

• 如果 rx_dropped 增加：可能是 CPU 满载，或者网卡 Ring Buffer 太小（可用 ethtool -G 调整）。
• 如果 tx_dropped 增加：可能是发送队列拥堵。

场景 2：网络间歇性断开，怀疑网线坏了

检查 CRC 错误和载波错误：

cat /sys/class/net/ens33/statistics/rx_crc_errors
cat /sys/class/net/ens33/statistics/tx_carrier_errors

• 如果这两个值在增加，90% 是物理链路问题（换根网线、换个交换机端口，或者检查是否有强电磁干扰）。

场景 3：计算实时网速 (Shell 脚本示例)

#!/bin/bash
IFACE="ens33"
RX1=$(cat /sys/class/net/$IFACE/statistics/rx_bytes)
TX1=$(cat /sys/class/net/$IFACE/statistics/tx_bytes)
sleep 1
RX2=$(cat /sys/class/net/$IFACE/statistics/rx_bytes)
TX2=$(cat /sys/class/net/$IFACE/statistics/tx_bytes)

RX_SPEED=$(( (RX2 - RX1) ))
TX_SPEED=$(( (TX2 - TX1) ))

echo"下载速度: $RX_SPEED Bytes/s"
echo"上传速度: $TX_SPEED Bytes/s"

• 正常情况：rx_bytes 和 tx_bytes 随时间增长，其他所有 error、dropped、fifo、crc 等错误计数值应保持为 0 或长期不变。
• 异常情况：一旦错误计数值开始持续增加，就说明网络存在隐患（硬件故障、配置不当或系统负载过高）。

四、/sys/class/net/ens33/queues/rx-0RPS (Receive Packet Steering，接收包转向) 技术的核心配置项。

背景：为什么要用 RPS？

在多核 CPU 服务器上，默认情况下，网卡可能只通过一个硬件中断将数据包发送给某一个 CPU 核心处理。

• 后果：如果网络流量很大，这一个 CPU 核心会满载（100%），而其他核心却在空闲。这会导致网络吞吐量上不去，甚至出现丢包。
• 解决：RPS 是一种软件层面的负载均衡技术。它允许网卡驱动程序将接收到的数据包“分发”给多个 CPU 核心共同处理，从而充分利用多核性能。

---

1. rps_cpus (核心配置文件)

• 含义：指定哪些 CPU 核心可以参与处理该队列（rx-0）接收到的网络数据包。

• 格式：CPU 掩码 (CPU Mask)，使用十六进制表示。

• 每一位二进制代表一个 CPU 核心。

• 1 表示允许该核心处理，0 表示不允许。

• 默认值：通常是 0，表示禁用 RPS，仅由触发中断的那个 CPU 处理。

• 如何计算：

• CPU 0 = 1 (二进制 0001) -> 十六进制

• CPU 0,1 = 3 (二进制 0011) -> 十六进制

• CPU 0,1,2,3 = 15 (二进制 1111) -> 十六进制

• CPU 0-7 = ff

• CPU 0-15 = ffff

• 操作示例（让 CPU 0, 1, 2, 3 共同处理 rx-0 队列）：

# 写入十六进制值 f (二进制 1111，代表前4个核)
echo f > rps_cpus

# 验证
cat rps_cpus

• 注意：如果你有 32 个或更多核心，需要计算更长的十六进制掩码（例如 ffffffff 代表前 32 核）。

2. rps_flow_cnt (流表大小配置)

• 含义：设置 RPS 用于跟踪网络流（Flow）的哈希表大小。

• 作用：

• RPS 需要根据数据包的源/目的 IP 和端口计算哈希值，将同一个连接（流）的数据包始终发给同一个 CPU，以保证 TCP 协议的正确性（避免乱序）。

• 这个文件定义了哈希表的大小（必须是 2 的幂次方，如 32768, 65536 等）。

• 默认值：通常为 0（表示使用内核默认值，或者未启用时的默认小表）。

• 调优建议：

• 如果并发连接数非常大（如高并发 Web 服务器、网关），默认的哈希表可能太小，导致哈希冲突增加，负载均衡效果变差。

• 可以根据内存情况适当调大，例如 32768 或 65536。

• 计算公式：建议设置为 期望并发连接数 / CPU 核心数 的 2 的幂次方近似值。

• 操作示例：

# 设置流表大小为 32768
echo 32768 > rps_flow_cnt

---

实战场景：解决“单核跑满，多核围观”问题

场景描述

你发现服务器网速只有 2Gbps，但 top 命令显示 CPU 3 利用率 100%，其他 CPU 利用率都很低。这说明网卡 rx-0 队列把所有压力都给了 CPU 3。

解决方案步骤

1. 查看当前配置：

cat /sys/class/net/ens33/queues/rx-0/rps_cpus
# 如果输出 0 或 8 (仅一个位为1)，说明 RPS 未生效或配置不当

1. 计算 CPU 掩码： 假设你有 8 个 CPU 核心 (0-7)，你想让它们一起干活。二进制：11111111 = 十六进制 ff。
2. 应用配置（对每个 rx 队列都要做，如果有 rx-1, rx-2 等）：

# 设置 rx-0 队列由所有 8 个核处理
echo ff > /sys/class/net/ens33/queues/rx-0/rps_cpus

# 可选：优化流表大小
echo 32768 > /sys/class/net/ens33/queues/rx-0/rps_flow_cnt

1. 验证效果：再次运行高负载网络测试，使用 mpstat -P ALL 1 观察是否所有 CPU 的网络中断软中断（si）负载都升起来了。

注意事项

1. 临时生效：直接 echo 写入这些文件是临时的，重启后失效。若要永久生效，需将命令写入 /etc/rc.local 或创建 udev 规则。
2. 队列对应：现代网卡通常有多个队列（rx-0, rx-1, rx-2…）。你需要对每一个队列单独配置 rps_cpus，通常会将不同的队列绑定到不同的 CPU 组，或者让所有队列共享所有 CPU（取决于具体策略）。
3. 性能开销：RPS 是软件模拟的，会消耗少量的 CPU 周期来进行数据包重定向。但在多核瓶颈场景下，这点开销远小于单核满载带来的收益。如果是万兆以上超高吞吐，建议优先检查网卡是否开启了 RSS (Receive Side Scaling)（硬件级负载均衡），RSS 优先级高于 RPS。

五、/sys/class/net/ens33/queues/tx-0包含了发送队列（Transmit Queue）的配置和统计信息。

与接收端（RX）的 RPS 技术相对应，发送端的核心优化技术是 XPS (Transmit Packet Steering)。这些文件主要用于控制数据包的发送速率、绑定 CPU 以及监控发送超时情况。

1.核心优化配置 (XPS)

这是提升多核服务器发送性能最关键的两个文件。

xps_cpus (可读写)

• 含义：指定哪些 CPU 核心 可以使用这个发送队列（tx-0）来发送数据。

• 作用：

• 默认情况下，内核可能会让所有 CPU 竞争同一个发送队列，导致锁竞争（Lock Contention），降低性能。

• 通过配置 xps_cpus，你可以将特定的 CPU 核心“绑定”到特定的发送队列上。例如，让 CPU 0-3 专门用 tx-0，CPU 4-7 专门用 tx-1。

• 这能显著减少多核环境下的锁争用，提升高并发下的网络吞吐量。

• 格式：十六进制 CPU 掩码（与 rps_cpus 格式相同）。

• 1 = CPU 0

• f = CPU 0,1,2,3

• ff = CPU 0-7

• 操作示例（允许 CPU 0 和 1 使用 tx-0 队列）：

echo 3 > xps_cpus  # 二进制 0011

xps_rxqs (可读写)

• 含义：指定哪些 接收队列（RX Queue） 的数据包在需要回复时，可以使用这个发送队列（tx-0）。

• 作用：

• 用于优化 TCP 协议栈的本地性。

• 当 CPU 处理完 rx-0 队列的数据包并需要发送 ACK 确认包或回复数据时，如果知道应该用哪个 TX 队列，就可以直接发送，避免跨队列查找。

• 通常设置为与 RX 队列对应的编号（例如 tx-0 对应 rx-0）。

• 格式：十六进制队列索引掩码。

• 1 = 对应 rx-0

• 3 = 对应 rx-0 和 rx-1

• 操作示例（让 tx-0 队列服务于 rx-0 队列的回复流量）：

echo1 > xps_rxqs

---

2.速率限制与监控

tx_maxrate (可读写)

• 含义：限制该发送队列的最大发送速率。

• 单位：Mbps (兆比特每秒)。

• 作用：

• 用于流量整形（Traffic Shaping）。你可以限制某个队列（进而限制绑定到该队列的特定业务或虚拟机）的带宽上限。

• 0 表示不限制（默认值）。

• 操作示例（限制 tx-0 队列最高只能跑 100Mbps）：

echo100 > tx_maxrate

• 注意：这需要网卡驱动支持。并非所有网卡驱动都实现了此功能。

tx_timeout (只读)

• 含义：记录该发送队列发生**超时（Timeout）**的次数。

• 作用：

• 故障排查关键指标。

• 当网卡驱动程序在预定时间内没有完成数据包发送（通常是硬件卡死或驱动 Bug），内核会触发“TX Timeout”，强制重置网卡。

• 如果这个数值持续增加，说明网卡驱动不稳定、硬件故障或系统负载过高导致中断响应太慢。这通常伴随着网络瞬间中断。

traffic_class (只读)

• 含义：显示该发送队列所属的流量类别（Traffic Class, TC）。

• 作用：

• 用于支持 QoS (服务质量) 和 DCB (数据中心桥接)。

• 支持 DCB 的网卡可以将流量分为多个优先级（如存储流量、管理流量、普通数据流量），每个类别有独立的发送队列。

• 普通环境下通常显示 0。

---

3.子目录：byte_queue_limits

• 含义：这是一个目录，里面包含更细粒度的字节队列限制配置（如 limit, limit_max 等）。

• 作用：

• 用于防止 Bufferbloat（缓冲区膨胀）。

• 它动态调整发送队列的长度，确保数据在队列中等待的时间不会过长，从而降低网络延迟（Latency），特别对实时交互业务（如语音、游戏、高频交易）有益。

• 通常由内核自动管理（BQL 算法），无需手动干预。

---

实战场景：优化高并发 Web 服务器

场景描述

服务器有 8 核 CPU，运行 Nginx。在高并发下，发现网络发送成为瓶颈，且 tx_timeout 偶尔增加。

优化步骤：启用 XPS

1. 查看当前状态：

cat tx_timeout  # 确认是否有超时
cat xps_cpus    # 确认是否已配置

1. 规划绑定策略：假设网卡有 2 个发送队列 (tx-0, tx-1)，我们有 8 个 CPU。

• tx-0 绑定 CPU 0, 1, 2, 3 (掩码 f)
• tx-1 绑定 CPU 4, 5, 6, 7 (掩码 f0)
• 同时关联 RX 队列：tx-0 对应 rx-0，tx-1 对应 rx-1。

1. 执行配置：

# 配置 tx-0
echo f > /sys/class/net/ens33/queues/tx-0/xps_cpus
echo 1 > /sys/class/net/ens33/queues/tx-0/xps_rxqs  # 对应 rx-0

# 配置 tx-1 (如果有)
echo f0 > /sys/class/net/ens33/queues/tx-1/xps_cpus
echo 2 > /sys/class/net/ens33/queues/tx-1/xps_rxqs  # 对应 rx-1 (二进制 10 = 2)

1. 验证效果：观察 tx_timeout 是否停止增长，并使用 sar -n DEV 1 观察发送吞吐量是否提升。

注意事项

1. 临时生效：同前，重启失效。需写入启动脚本。
2. 驱动支持：XPS 功能需要网卡驱动明确支持。如果写入后报错或不生效，请检查驱动文档或尝试更新驱动。
3. 队列数量：首先用 ls /sys/class/net/ens33/queues/ 确认你的网卡到底有几个 tx-x 队列。如果只有一个 tx-0，那么所有 CPU 都只能配给这一个队列，此时 XPS 的主要作用是减少锁竞争，而不是负载均衡到不同硬件队列。
4. tx_timeout 报警：如果 tx_timeout 很高，除了配置 XPS，更应优先检查是否中了“单核中断瓶颈”（配合 RPS 解决）或网卡硬件本身有问题。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：运维星火燎原 刘军军 刘军军《openEuler 网络核心诊断指南》