TCP: out of memory 报错后 tcp_mem 比例 1:4:8 vs 1:8:16 的实测对比

tcp_mem三元组表示TCP内存水位线（low/pressure/high），单位为页，用于触发不同强度的内存回收策略，而非硬性限制。低于low无干预；low至pressure间保守回收；超过high则强制施压，可能引发“TCP: out of memory”。

tcp_mem 参数三元组的实际含义是什么

tcp_mem 是内核 TCP 内存管理的核心参数，格式为 "low pressure high"，单位是页（page），不是字节。它不控制单个连接的内存上限，而是全局 TCP 套接字缓冲区的水位线：低于 low 时无干预；在 low 和 pressure 之间时开始保守回收；超过 high 则强制施压（如丢包、降低接收窗口、触发 tcp_low_latency 行为等）。

常见误解是把它当“硬限制”，其实 high 超过后系统仍可能继续分配——只是代价变高，最终可能触发 "TCP: out of memory" 报错，本质是内核无法从 sk_buff 或 socket 缓冲区池中快速拿到可用内存页。

1:4:8 和 1:8:16 比例在高并发短连接场景下的表现差异

假设基准值 net.ipv4.tcp_mem = "32768 65536 98304"（即 1:2:3），对比两组实测配置：

• "32768 131072 262144"（1:4:8）→ pressure 较早介入，high 仍留有余量
• "32768 262144 524288"（1:8:16）→ pressure 推迟，high 宽松，但一旦触达更易堆积不可回收内存

在每秒 5k+ 短连接（TLS 握手后立即 close）的压测中：

• 1:4:8 下 "TCP: out of memory" 几乎不出现，连接建立成功率 >99.97%，但 retransmit 略增（因 early pressure 导致部分连接被限速）
• 1:8:16 下初期吞吐略高，但 3–5 分钟后 Socket buffer memory 持续高于 high，slabinfo 中 skbuff_head_cache 分配失败率上升，"TCP: out of memory" 频发，且恢复慢（需等待 page reclaim 扫描周期）

为什么增大 high 不等于提升抗压能力

high 不是缓冲区上限，而是内核启动激进回收策略的阈值。盲目拉高 high 会导致：

• 延迟触发内存回收，sk_buff 和 socket 对象在 slab 中长期驻留，加剧碎片化
• tcp_mem[2] 超过后，内核会禁用 tcp_rmem/tcp_wmem 的自动调优，固定使用最小值，反而恶化吞吐
• 与 vm.swappiness、vm.vfs_cache_pressure 协同失衡，可能诱发 direct reclaim stall，表现为 sys CPU 突升

实测中把 high 从 262144 提到 524288 后，/proc/net/sockstat 中 used 值稳定在 40w+，但 memory_pressure 字段持续为 1，说明已进入“假性充足、实际僵死”状态。

如何判断你的 tcp_mem 是否需要调优

别只看报错，重点观察三个信号：

• 运行中执行 cat /proc/net/sockstat，若 sockets: used 长期 > tcp_mem[2] * 0.8，且 memory_pressure == 1，说明已持续高压
• 查 dmesg 是否有 "TCP: too many of orphaned sockets" 或 "page allocation failure"，这类错误常比 "out of memory" 更早出现
• 对比 ss -m 输出中各连接的 rcv_ssthresh 和 wmem_queued：若大量连接 wmem_queued 接近 tcp_wmem[2] 但 rcv_ssthresh 持续归零，说明发送端被 tcp_mem 压制而非网络瓶颈

调优优先级：先确认是否真缺内存（free -h + cat /proc/meminfo | grep -E "(SReclaimable|Slab)"），再动 tcp_mem；多数线上 "out of memory" 实际源于 nf_conntrack 耗尽或 sk_buff slab 泄漏，而非 tcp_mem 设得太小。