“TCP: out of memory”报错直接对应tcp_mem[2]（high），但真正决定系统是否提前崩溃的是tcp_mem[1]（pressure）的触发时机；low仅作安静区起点，pressure才是缓冲收缩、ACK延迟、窗口压制的开关，1:4:8为高并发短连接最优比例。
“TCP: out of memory”到底卡在哪个水位？
报错直接对应 tcp_mem[2]（high），但真正决定系统是否“提前崩溃”的，是 tcp_mem[1]（pressure）的触发时机。low 只是安静区起点，不参与报错逻辑；high 超过即丢包、拒连、打日志；而 pressure 才是缓冲区开始收缩、ACK 延迟、窗口压制的开关——它决定了你还有没有“抢救窗口”。
1:4:8 是高并发短连接场景下最稳的比例
实测中，把 net.ipv4.tcp_mem 设为 "32768 131072 262144"（即 1:4:8）在每秒 5k+ TLS 短连接压测中表现最优：
- pressure 在总用量达 ~512MB（131072 × 4KB）时介入，及时收缩
tcp_rmem/tcp_wmem，避免 sk_buff 长期驻留 slab - high 留有约 1GB 缓冲余量（262144 × 4KB），既防突增流量冲击，又不致因过高导致回收惰性
- 连接成功率 >99.97%，
/proc/net/sockstat中memory_pressure字段极少持续为 1 - 重传率略升（+0.12%），但远优于
1:8:16下的连接雪崩
别碰 1:8:16 —— 它放大的是风险，不是容量
看似 high 更大、能扛更多连接，实际是把问题拖到更糟阶段：
- pressure 推迟到 ~1GB 才启动，期间 socket 缓冲区持续膨胀，
skbuff_head_cache分配失败率快速上升 - 一旦越过 high（如
"32768 262144 524288"），内核禁用自动调优，固定使用tcp_rmem[0]（4KB），吞吐断崖下跌 -
/proc/net/sockstat显示used长期 >40w，但memory_pressure == 1持续存在 → “内存充足假象”，实为 slab 碎片化僵死 - 恢复依赖 page reclaim 扫描周期（默认数百毫秒），期间新连接大量被 SYN drop
怎么定你的绝对值？看 /proc/net/sockstat 而不是拍脑袋
比例只是骨架，真值得从运行态反推：
- 执行
cat /proc/net/sockstat，重点关注sockets: used和memory_pressure - 若
used常 >tcp_mem[2] × 0.8且memory_pressure == 1，说明已长期高压，必须调 - 先扩 low 和 pressure（保持 1:4），再按需抬 high；例如当前
"196608 786432 1179648"，可试"262144 1048576 1572864" - 调完立刻观察
dmesg | grep "TCP:.*out of memory"和ss -s的total/orphan变化
记住：tcp_mem 不是缓冲区上限，而是内核行为开关。调 high 不等于加内存，而是推迟回收——拖得越久，代价越不可逆。
