tcp_mem三元组以页为单位，分别表示低水位、压力模式起始点和高水位；超过第三值将触发OOM killer。其实际阈值需结合页大小（通常4KB）与内存总量计算，且必须与tcp_rmem/tcp_wmem等参数协同调整才能有效提升吞吐。
tcp_mem 参数三元组的实际含义不是内存大小，而是页数
linux 的 tcp_mem 是以「内存页（page）」为单位的，不是字节或 MB。比如 net.ipv4.tcp_mem = 123456 234567 345678 表示：当 TCP 使用的内存页数低于第一个值时无限制；在第一个和第二个值之间时进入“压力模式”（开始丢包、降低接收窗口）；超过第三个值则直接拒绝新连接或丢弃入包。
所以对比 1:2:4 和 1:4:8 时，不能只看比例，必须结合系统页大小（通常是 4KB）和当前内存总量算出实际阈值。例如在 64GB 内存机器上，tcp_mem 默认常是 98304 131072 196608（对应约 384MB / 512MB / 768MB），此时 1:2:4 ≈ 98K/196K/392K 页，而 1:4:8 ≈ 98K/392K/784K 页——高水位翻倍，意味着更晚触发强制回收，但也更容易耗尽内存。
“out of memory” 报错通常发生在 high watermark 被突破后，内核放弃分配页
这个错误不是 TCP 协议栈自己报的，而是内核在 sk_stream_alloc_skb() 或 tcp_sendmsg() 中调用 alloc_pages() 失败时回退到 OOM killer 流程，最终在 dmesg 里看到类似：
TCP: out of memory — consider tuning tcp_mem此时说明已越过 tcp_mem[2]（即第三个值），且系统无法满足 socket 缓冲区申请。常见诱因包括：
- 突发大流量 + 小
tcp_rmem/tcp_wmem导致缓冲区频繁重分配 - 大量空闲但未关闭的 ESTABLISHED 连接持续占着
sk->sk_rcvbuf -
tcp_mem[2]设置过低，而net.core.wmem_max或rmem_max又过高，造成单连接可占页数远超预期
1:2:4 和 1:4:8 在吞吐上的差异取决于流量模式而非比例本身
实测中，两者吞吐差异往往不显著，除非压测场景极端：
- 短连接洪峰（如 http API 批量请求）：1:4:8 更容易触发 early drop，反而吞吐略降，因为连接被
tcp_enter_memory_pressure()提前限速 - 长连接大数据流（如 rsync over TCP、视频推流）：1:4:8 允许更大缓存堆积，BDP（带宽时延积）匹配更好，吞吐可能提升 5–10%，但前提是
tcp_rmem[2]也同步调大，否则受限于 per-socket 上限 - 混合负载下，1:2:4 响应更“保守”，OOM 更少；1:4:8 容忍度高，但一旦打满，OOM 杀进程更猛烈
真正影响吞吐的是 tcp_rmem 和 tcp_wmem 的第二、第三个值是否匹配 RTT 和带宽，而不是 tcp_mem 比例。
调参前必须检查 per-socket 缓冲区与全局内存的对齐关系
tcp_mem 不是孤立参数。它和以下设置强耦合：
-
net.core.rmem_max和wmem_max必须 ≥tcp_rmem[2]和tcp_wmem[2]，否则 socket 无法达到理论最大缓冲 -
tcp_rmem[0]和tcp_wmem[0]影响初始窗口，太小会导致慢启动效率低 - 若启用了
net.ipv4.tcp_window_scaling=1（默认开启），则需确保tcp_rmem[2] ≥ 65535 × 2^14（即支持最大窗口），否则窗口缩放失效
一个典型易错配置是把 tcp_mem 设成 1:4:8，但 tcp_rmem 仍为默认 4096 16384 4194304，此时即使全局允许 800MB，单连接最多只用 4MB，根本用不到 high watermark。
真正卡住吞吐的，往往是 per-socket 限制没放开，而不是 tcp_mem 比例不对。