甲骨云 ARM 服务器 TCP 内核调优——让 BBRv3 在 virtio + 跨境链路上跑满

TL;DR：甲骨文 ARM 实例默认的内核参数对"高 BDP + 多队列 virtio"并不友好——rmem_max 偏小、fq quantum 沿用 1514、tcp_notsent_lowat 未设会导致 sender 侧 bufferbloat。本文给出一套针对跨境/高 RTT 场景的 sysctl + MTU + fq 调优，配合 BBRv3 使用，避免在长肥管道上"跑不满"。

背景：为什么甲骨云 ARM 需要单独调

甲骨文 ARM（Ampere A1，enp0s6 + virtio-net）有几个特征，让默认内核参数不够用：

virtio-net 多队列：ARM 实例一般 expose 多个 TX 队列，默认 fq 是单队列挂在 root 上，mq 场景下 pacing 会退化
跨境/高 RTT：如果你拿它做跨境出口，RTT 100–300 ms 是常态，BDP = BW × RTT 很容易飙到几十 MB
默认 rmem_max / wmem_max 偏小：不少发行版停在 4–8 MB，BDP 一大就成瓶颈
tcp_notsent_lowat 未设：sender 会把已发但未 ACK 的数据全堆在 TCP 层，叠加 BBR pacing 反而让应用侧感知延迟
MTU分层特性：VPC内部默认MTU为9000，但公网出口会强制切分为1500，若实例侧不手动锁定1500，易触发PMTU发现失效与跨境链路隐形丢包，因此下文 MTU 与 fq 参数均按出口 1500 计算
BBRv3的pacing敏感性：BBRv3相比v1收紧了inflight控制，若qdisc层burst过大，会抵消拥塞控制的精细调控，导致高丢包场景下误降发送速率

💡 这组调优不是为了"极限跑分"，而是让 BBRv3 / BBRv3+LFN 在甲骨云 ARM 上不被内核参数自己掐脖子。

核心思想：四件套各管一段

层级调优项目标Socket缓冲区tcp_rmem/tcp_wmem + rmem_max/wmem_max高BDP场景下不触顶Sender节流tcp_notsent_lowat=16384限制未发送队列长度，降低应用侧延迟窗口与重传adv_win_scale=1、retries2=8高RTT场景下平衡乱序容错与超时判定Qdisc调度fq quantum=12500 initial_quantum=35000匹配1500 MTU出口粒度，避免pacing被切碎

注：以下所有fq参数均按公网出口1500 MTU计算，适配跨境链路特性。

一、sysctl：缓冲区与 sender 侧优化

cat > /etc/sysctl.d/99-tcp-ora.conf << 'EOF'
# 拥塞控制（需内核已集成BBRv3）
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

# 全局Socket缓冲区上限（与TCP专用配置对齐）
net.core.rmem_default = 262144
net.core.rmem_max   = 134217728   # 128MB，预留2倍BDP余量
net.core.wmem_default = 262144
net.core.wmem_max   = 134217728

# TCP专用三档配置：min/default/max
net.ipv4.tcp_rmem = 8192 131072 134217728
net.ipv4.tcp_wmem = 4096 16384  134217728

# Sender节流：限制未发送数据量，避免BBR pacing时应用侧数据堆积
net.ipv4.tcp_notsent_lowat = 16384

# 接收窗口调整：高重排跨境链路下，预留1/2 skb空间给乱序包（默认仅1/4）
net.ipv4.tcp_adv_win_scale = 1

# 高RTT链路重试优化：从默认15次降至8次，避免链路抖动时连接长时间假死
net.ipv4.tcp_retries2 = 8

# 基础功能开关
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
EOF
sysctl --system

二、MTU配置：锁定1500适配公网出口

甲骨云VPC内默认MTU为9000，但公网出口会强制降级为1500，手动锁定1500可避免PMTU发现失效与跨境链路丢包：

# /etc/netplan/50-cloud-init.yaml
network:
  version: 2
  ethernets:
    enp0s6:
      match:
        macaddress: "02:00:17:06:a9:b5"
      dhcp4: true
      set-name: "enp0s6"
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 1.1.1.1
          - 2606:4700:4700::1111
      mtu: 1500

⚠️ 切勿盲目开启9000 MTU：甲骨云部分区域公网overlay不支持Jumbo帧，设置后会出现分片甚至丢包，1500是所有公网场景的兼容公约数。

自动适配多队列的fq配置脚本

以下脚本会自动检测TX队列数量，挂载MQ+fq，默认采用保守跨境档，BBRv1用户可将数值修改为平衡档：

#!/bin/bash
# /etc/networkd-dispatcher/routable.d/50-ifup-hooks
# 权限：chmod +x，启用：systemctl enable --now networkd-dispatcher
# 注：甲骨云VPC内默认MTU为9000，本配置针对公网出口1500 MTU场景优化
# 若主要用于VPC内9000 MTU大流量互拷，可按比例放大quantum与initial_quantum

IFACE_NAME="enp0s6"

[ ! -d "/sys/class/net/$IFACE_NAME" ] && exit 0
[ "$IFACE" != "$IFACE_NAME" ] && [ -n "$IFACE" ] && exit 0

TX_COUNT=$(ls -d /sys/class/net/$IFACE_NAME/queues/tx-* 2>/dev/null | wc -l)
echo "Detected $TX_COUNT TX queues on $IFACE_NAME"

tc qdisc del dev $IFACE_NAME root 2>/dev/null

if [ "$TX_COUNT" -gt 1 ]; then
    echo "Applying MQ + FQ (multi-queue, targeting egress MTU 1500)"
    tc qdisc replace dev $IFACE_NAME root handle 1: mq
    for ((i=1; i<=TX_COUNT; i++)); do
        # 保守跨境档：适配BBRv3与跨境链路
        tc qdisc replace dev $IFACE_NAME parent 1:$i \
            fq quantum 12500 initial_quantum 35000
        # BBRv1用户可切换为平衡档：
        # tc qdisc replace dev $IFACE_NAME parent 1:$i \
        #     fq quantum 18028 initial_quantum 90140
    done
else
    echo "Applying FQ (single-queue, targeting egress MTU 1500)"
    tc qdisc replace dev $IFACE_NAME root \
        fq quantum 12500 initial_quantum 35000
fi

参数设计逻辑

quantum=12500：约等于8个1500 MTU帧，让一个pacing时隙内可连续dequeue 8帧，既避免pacing被qdisc切碎，又不会因单次dequeue过多导致多流不公平
initial_quantum=35000：约等于23个1500 MTU帧，满足慢启动初期的窗口填充需求，又不会在出口1500 MTU的浅队列上一次性注入过多数据导致拥塞

FQ Quantum 调度优化

默认fq的quantum=1514、initial_quantum=15140按传统以太帧设计，在BBR pacing场景下会出现dequeue次数过多、pacing精度下降的问题。
quantum=18028、initial_quantum=90140按 VPC 内 MTU9000 计算出

以下是三个常用档位的对比（按公网1500 MTU计算）：

默认
(1514 / 15140)保守跨境档
(12500 / 35000)平衡档
(18028 / 90140)BBRv1 吞吐吃亏，softirq 高够用最舒服BBRv1 RTT 波动稳稳略飘（初始 burst 60 帧）BBRv3 吞吐吃亏最优能跑满，但丢包 1–3% 时 inflight_hi 易被误导BBRv3 RTT 波动稳但 pacing 碎最平偏飘多流公平好中差ARM softirq高中低适用场景不推荐BBRv3/多流混跑/跨境链路BBRv1/单流自用

💡 BBRv1 vs BBRv3 的 fq 选型差异

BBRv1 自身 pacing 较粗，依赖 qdisc 侧适度 burst 补间隙，可用 quantum 18028 initial_quantum 90140（≈1500×12 / 1500×60）；
BBRv3 收紧了 inflight 控制，qdisc burst 过大会抵消 pacing 精度，跨境高丢包场景下建议改用 quantum 12500 initial_quantum 35000（≈1500×8 / 1500×23）。
多流混跑场景（代理+rsync+docker 同台）无论 v1/v3 均建议 12500/35000。

BBR/LFN补丁的搭配

场景拥塞控制fq配置备注甲骨云ARM单机+跨境BBRv3原生保守跨境档丢包<2%场景最优同上+丢包2-8%BBRv3+LFN补丁保守跨境档详见/archives/22/多流混跑（代理+备份+容器）BBRv3+LFN保守跨境档避免单流抢占全部带宽旧内核仅支持BBRv1BBRv1平衡档单流自用场景性能最优

预期效果（ARM c8y 4c24g + 跨境200ms RTT实测）

指标默认参数调优后单流BBRv3吞吐（1Gbps线路）~620Mbps（rmem触顶）~940Mbpsss -ti skmem状态频繁触达rmem_max稳定在30-60MB区间应用write延迟波动幅度>50%16KB封顶，波动<10%fq pacing完整性时隙内dequeue次数过多8帧/时隙，pacing无断裂

注意事项

⚠️ rmem_max请勿设置超过256MB，避免内存溢出风险
⚠️ tcp_retries2=8在RTT>500ms的链路上可进一步降至5-6，避免超时等待过长
✅ adv_win_scale=1在重排较少的内网场景下可改回2，降低内存占用
✅ 若主要用于VPC内9000 MTU场景的大流量互拷，可按比例放大quantum与initial_quantum，本配置针对公网出口优化
🔍 可通过tc -s qdisc show dev enp0s6验证效果：若throttled高但unthrottled低，需适当增大quantum；若慢启动阶段dropped突增，需减小initial_quantum

本调优未引入非标准补丁，仅在甲骨云ARM的网络特性基础上，将内核参数从"通用默认值"调整为"长肥管道友好值"。配合BBRv3或BBRv3+LFN补丁使用，可避免带宽瓶颈到来前被socket缓冲区与qdisc调度提前限制。

当前页面是本站的「Google AMP」版。查看和发表评论请点击：完整版 »