【网络】Linux 内核优化实战 - net.core.netdev

net.core.netdev_budget 是 Linux 内核中的网络参数，用于控制 单次网络软中断（NET_RX_SOFTIRQ） 处理的最大数据包数量。其核心作用是平衡网络吞吐量与系统响应性，避免网络处理过度占用 CPU 资源，导致其他任务（如用户进程）延迟。

网络数据包处理流程
- 硬件中断：网卡接收到数据包后，触发硬件中断通知 CPU。
- 软中断调度：CPU 响应中断后，将数据包处理任务放入软中断队列，快速返回处理其他任务。
- 软中断处理：内核在合适时机（如空闲时）执行软中断，批量处理网络数据包。
netdev_budget 的限制
- 每次软中断处理时，内核最多从所有网络接口读取并处理 netdev_budget 个数据包。
- 处理完成后，若仍有未处理的数据包，内核会重新调度软中断，继续处理剩余数据。

默认值：通常为 300（不同内核版本可能略有差异，可通过 sysctl net.core.netdev_budget 查看）。
配置方式：
- 临时修改（生效至重启）：
```
sysctl -w net.core.netdev_budget=600  # 增加至600
```
- 永久修改：编辑 /etc/sysctl.conf，添加或修改：
```
net.core.netdev_budget = 600
```
  保存后执行 sysctl -p 生效。

高流量服务器（如负载均衡器、CDN）
- 问题：默认值可能导致软中断频繁触发，增加上下文切换开销。
- 调整：增大 netdev_budget（如 1000-2000），减少软中断次数，提升吞吐量。
- 风险：单次软中断处理时间延长，可能影响其他任务响应（如系统调用延迟）。
低延迟敏感型应用（如数据库、实时通信）
- 问题：大 netdev_budget 可能导致软中断占用 CPU 时间过长，影响关键进程。
- 调整：减小 netdev_budget（如 100-200），增加软中断频率但缩短单次处理时间。
- 配合优化：结合 net.core.netdev_budget_usecs（控制软中断最大持续时间）使用。
多队列网卡环境
- 问题：多队列网卡可并行接收数据，默认值可能无法充分利用硬件能力。
- 调整：增大 netdev_budget，并结合 net.core.netdev_max_backlog（接收队列长度）优化。

net.core.netdev_budget_usecs
- 控制单次软中断的最大执行时间（单位：微秒）。若处理时间超过该值，即使未达到 netdev_budget 的数据包数量，也会停止处理。
- 示例配置：
```
net.core.netdev_budget = 1000       # 增加数据包处理数量
net.core.netdev_budget_usecs = 4000  # 限制单次软中断时间为4ms
```
net.core.netdev_max_backlog
- 定义网卡接收队列的最大长度。若数据包处理速度跟不上接收速度，队列会暂存数据包。
- 高流量场景需同步增大该值（如 30000-65535），避免队列溢出导致丢包。
网卡多队列配置
- 通过 ethtool -L eth0 combined N 设置网卡接收队列数（N 为 CPU 核数），并结合 irqbalance 工具将中断负载分散到多个 CPU，提升并行处理能力。

监控软中断负载

# 查看软中断统计（关注 NET_RX 行）
cat /proc/softirqs

# 实时监控 CPU 软中断占用率
mpstat -P ALL 1 | grep %soft

检测丢包情况

# 查看网卡统计信息（关注 rx_dropped 指标）
ethtool -S eth0

# 使用 ss 命令监控套接字丢包
ss -s | grep packets

性能测试工具

使用 iperf3 或 netperf 测试不同 netdev_budget 设置下的吞吐量和延迟：

# 服务端
iperf3 -s
# 客户端（测试 TCP 吞吐量）
iperf3 -c server_ip -t 30 -P 8  # 8 并发，测试 30 秒

过度增大的风险
- 若 netdev_budget 设置过大（如 >5000），可能导致：
  - 单次软中断处理时间过长，造成其他进程（如 SSH、数据库）响应延迟；
  - 接收队列积压，增加端到端延迟。
生产环境建议
- 通用服务器：保持默认值（300）或微调至 500-1000。
- 高流量专用服务器：逐步增大至 2000-4000，并配合 netdev_budget_usecs 控制时间。
- 测试方法：在测试环境中逐步调整参数，通过 perf 或 systemtap 分析网络栈瓶颈。