OpenWrt测速时CPU占用过高如何优化？

Question

在使用OpenWrt进行网络测速时，常出现CPU占用率过高（接近100%）的问题，尤其在低端路由器或老旧设备上更为明显。该问题主要源于测速过程中大量小数据包的处理、加密流量计算（如HTTPS）、以及QoS或防火墙规则的深度包检测，导致CPU成为性能瓶颈。如何在不影响测速准确性的前提下，优化系统配置以降低CPU负载，成为OpenWrt用户普遍关注的技术难题。

Answer 1

1. 问题背景与现象分析

在使用OpenWrt进行网络测速时，尤其是在低端或老旧设备上（如MT7620、AR9344等SoC平台），用户普遍反映CPU占用率接近100%，导致系统响应迟缓甚至测速中断。该现象的核心在于：测速工具（如iperf3、speedtest-cli）在高并发连接下产生大量小数据包，而OpenWrt的Linux内核需逐包处理网络协议栈操作，包括TCP/IP校验、NAT转换、防火墙规则匹配、QoS分类等。

尤其当启用HTTPS加密流量模拟或开启深度包检测（DPI）功能时，TLS加解密运算进一步加重CPU负担。例如，在运行Ookla Speedtest CLI时，其默认使用多线程HTTPS连接，每个连接都涉及SSL握手和加密传输，这对缺乏硬件加密加速的设备构成显著压力。

2. 核心瓶颈拆解

通过top、htop、nethogs等工具监控可识别以下主要负载来源：

• 协议栈处理开销：每秒数万个小包（如64字节）触发频繁中断，消耗大量CPU周期。
• Netfilter/Iptables规则遍历：每条数据包需遍历iptables FORWARD链，若启用QoS（如SQM）、家长控制或GeoIP过滤，规则集庞大导致性能下降。
• 加密运算无硬件卸载：ARM架构多数无AES-NI指令集，软件实现TLS效率低下。
• 调度延迟与上下文切换：多线程测速引发进程频繁切换，加剧资源竞争。

3. 系统级优化策略

优化方向	具体措施	适用场景
关闭非必要服务	停用dnsmasq DNSSEC、uhttpd HTTPS管理界面	所有设备
调整IRQ亲和性	将网络中断绑定至特定CPU核心	多核SoC设备
启用快速转发	配置flow offloading或shortcut-fe	支持netfilter flow机制
精简防火墙规则	移除冗余规则，避免LOG动作滥用	高规则数量环境
关闭TCP Segmentation Offload	set: ethtool -K eth0 tso off gso off	虚拟化或兼容性问题
升级内核版本	使用5.4+内核提升协议栈效率	支持新固件的设备
启用BBR拥塞控制	sysctl -w net.ipv4.tcp_congestion_control=bbr	高延迟链路
限制测速并发数	speedtest --threads 2 而非默认8线程	低内存/单核设备
使用轻量测速客户端	替换为iperf3或自建HTTP大文件下载	规避加密开销
启用硬件加速	配置MT76驱动offload、switch VLAN硬件转发	Mediatek平台设备

4. 关键配置代码示例

# 启用Flow Offloading（需安装package: flow-offload）
uci set firewall.@defaults[0].flow_offloading=1
uci set firewall.@defaults[0].flow_offloading_hw=1  # 若支持硬件卸载
uci commit firewall

# 加载nf_flow_table模块
modprobe nf_flow_table
modprobe nf_flow_table_inet

# 优化TCP参数
echo 'net.core.rmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_fin_timeout = 15' >> /etc/sysctl.conf
sysctl -p

5. 测速方法论重构

为降低CPU依赖同时保持测速准确性，建议采用分层测速模型：

1. 第一阶段：使用未加密iperf3 TCP测试（端口5201），禁用窗口缩放，设置合理缓冲区大小（-w 64K）
2. 第二阶段：执行UDP打流测试，验证实际带宽与丢包率
3. 第三阶段：仅在必要时运行HTTPS-based speedtest-cli，并限制线程数
4. 第四阶段：对比前后结果，分离加密层性能损耗

6. 性能监控与归因流程图

graph TD
    A[开始测速] --> B{CPU是否≥90%?}
    B -- 是 --> C[启用top/htop实时监控]
    C --> D[定位高耗进程: speedtest/iperf3/ksoftirqd]
    D --> E{是否为ksoftirqd占优?}
    E -- 是 --> F[判断为中断处理瓶颈]
    E -- 否 --> G[检查用户态进程加密开销]
    F --> H[启用flow offloading或IRQ平衡]
    G --> I[改用非加密测速或降并发]
    H --> J[重新测速并记录结果]
    I --> J
    J --> K[输出优化后数据对比表]