Linux

«结论先行：同机房 TCP 重传率哪怕只有 0.4%，只要命中的是带业务语义的长连接（DB、RPC、WebSocket），P99 立刻翻 5–20 倍——因为 RTO 是指数退避的，重传一次 RTO 就翻倍，重传五次就 32 倍，而 "tc

背景 我们有一个 12 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v2，内核 5.15）的集群，文件存储走自建 NFS（NFSv4，服务端是 4 台 8C32G 的独立机器

«结论先行："free -h" 显示还有 40G 空闲、机器也没 OOM，但 JVM / Python / Node 进程就是起不来、报 "Cannot allocate memory (ENOMEM)"——十有八九不是内存真不够，而是内核

一、现象与背景 先给结论：这次毛刺的根因既不是 InnoDB、不是 binlog、不是网络，而是 Linux 内核的 page cache 回写策略——"vm.dirty_ratio" 默认 20% 在 32GB 内存的机器上等于允许 6.

【背景】 我在 Linux（Ubuntu 22.04 / kernel 5.15）上跑一批 Java gRPC 微服务，单 Pod 并发连接 2000+，业务方偶尔报"接口偶发变慢"，但应用侧 trace 里 handler 耗时看着正常。