ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Linux 网络调优:先测软中断、队列与连接状态

Linux 网络调优:先测软中断、队列与连接状态 Linux 网络调优先测软中断、队列与连接状态Linux 网络调优先建立基线软中断分布、队列溢出、重传与连接状态。改一个参数就复测一轮记录内核、网卡和负载生成器没有这些条件的吞吐数字无法外推。1. 负载上升后检查网卡 TX/RX 队列先执行mpstat -P ALL 1查看各 CPU 的软中断分布不预设哪一个核心一定是瓶颈mpstat -P ALL 1再检查网卡收包统计并将eth0替换为目标接口ethtool -S eth0 | grep -E drop|fifo|miss|error如果rx_dropped或rx_fifo_errors在负载期间持续增加再结合 Ring Buffer、驱动统计和softnet_stat判断丢包发生在哪一层。累计计数本身不能说明当前仍在丢包。在现代 Linux 系统中如果忽视网卡中断分布与内核网络协议栈的调优高并发流量容易死死卡在单核软中断瓶颈上无法发挥出多核服务器的硬件极限。2. 硬中断单核瓶颈拆解RPS/RFS 负载均衡与 TCP 窗口协商原理要尽量攻克这个单核软中断瓶颈需要拆解数据包从物理网卡到达用户态应用程序的完整链路。当数据包到达网卡时物理网卡通过 DMA 将数据写入 RX Ring Buffer随后向 CPU 触发一个硬件中断IRQ。由于历史原因Linux 内核默认可能将网卡的所有 IRQ 中断全部路由给系统默认的CPU 0处理。CPU 0 在响应硬中断后触发NET_RX_SOFTIRQ软中断将包从 Ring Buffer 拷贝到内核sk_buff并沿着 TCP/IP 协议栈层层向上推送。在高并发场景下CPU 0 处理软中断的速度跟不上网卡收包速率导致 Ring Buffer 被迅速填满丢包。解决问题的根本方案有两个维度多队列网卡硬中断绑定SMP IRQ Affinity对于支持多队列Multi-Queue的万兆网卡将不同的 RX/TX 队列硬件中断均衡分配绑定到不同的 CPU 核心上如 Queue 0 绑定 CPU 0Queue 1 绑定 CPU 1。单队列网卡的 RPS/RFS 软件分流Receive Packet Steering / Receive Flow Steering如果网卡只支持单队列开启内核的 RPS/RFS 机制在内核协议栈入口处通过 Socket 四元组 Hash 计算将数据包的软中断处理分发到不同的 CPU 核心上实现多核并行协议栈解析。下面是经过中断亲和性绑定与内核协议栈调优后的网络收包走向图完成这一层治理后可以把网络协议栈的处理能力扩展到服务器的所有物理核心上。3. 先用只读脚本收集网卡队列、IRQ 与内核参数中断亲和性、Ring Buffer 和 TCP 参数都会影响整台节点不适合由文章脚本一次性覆盖。下面的脚本只收集现状变更时每次只选择一个候选项并通过节点级 Canary 验证。#!/usr/bin/env bash # # Linux 网络队列、IRQ 与 sysctl 只读盘点脚本 set -euo pipefail INTERFACE${1:-eth0} echo 网卡 ${INTERFACE} 信息 if ! ethtool -i ${INTERFACE} /dev/null 21; then echo 错误: 网卡设备 ${INTERFACE} 不存在 exit 1 fi ethtool -g ${INTERFACE} || true ethtool -l ${INTERFACE} || true ethtool -S ${INTERFACE} | grep -E drop|fifo|miss|error || true echo IRQ 与亲和性 IRQS$(grep ${INTERFACE} /proc/interrupts | awk -F: {print $1} | tr -d ) for IRQ in ${IRQS}; do printf IRQ %s affinity ${IRQ} cat /proc/irq/${IRQ}/smp_affinity_list 2/dev/null || true done echo RPS 配置 for rps_file in /sys/class/net/${INTERFACE}/queues/rx-*/rps_cpus; do [ -f ${rps_file} ] printf %s ${rps_file} cat ${rps_file} done echo 相关 sysctl sysctl net.core.netdev_max_backlog net.core.somaxconn \ net.core.rmem_max net.core.wmem_max \ net.ipv4.tcp_congestion_control盘点结果用于提出候选改动而不是直接把队列调到硬件最大值。尤其不要在未确认 NUMA、IRQ 队列和运维策略前停用irqbalance拥塞控制算法也应确认内核支持并做外部网络对照。4. 验证口径与记录方法压测过程中使用sar -n DEV 1监控网卡数据包吞吐使用mpstat观察 CPU 软中断分布。先测只改变一个 sysctl 的版本再测 IRQ/RPS 候选方案避免把多项改动的收益混在一起指标节点当前配置单项 sysctl 候选IRQ/RPS 候选容量边界同一脚本逐级加压同一脚本逐级加压同一脚本逐级加压P99 延迟保存原始样本保存原始样本保存原始样本CPU 软中断mpstat -P ALLmpstat -P ALLmpstat -P ALL网卡丢包增量ethtool -S差值同一时间窗差值同一时间窗差值网络吞吐sar -n DEVsar -n DEVsar -n DEV连接错误按错误类型计数按错误类型计数按错误类型计数5. 生产环境内核参数变更的 Canary 灰度回滚机制在对生产环境进行 Linux 内核参数变更时需要时刻警惕盲目全局覆盖可能带来的潜在风险。例如过大的rmem_max如果在数万并发连接下被全部申请容易引发系统的 OOM Killer。为了保障线上基础设施的确定性安全需要建立 Canary 灰度发布与自动化回滚机制备份还原点配置在修改/etc/sysctl.d/或配置/proc/文件前脚本需要自动将当前原生的内核参数导出备份至/etc/sysctl.d/backup_sysctl_YYYYMMDD.conf。设置自动回滚哨兵在 Canary 变更期间持续观察 OOM、丢包率和延迟。观察窗口要覆盖典型负载周期指标越过发布门槛时再执行已演练的回滚脚本并校验参数确已恢复。收尾
返回列表