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 reclaimstall，表现为 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 设得太小。
