Java 服务 P99 偶发 300–800ms 毛刺（JVM/GC/应用日志全绿）：khugepaged 合并、邻居 IO、CPU 迁移——线上到底怎么系统排除？

背景

5 年运维，管一个 K8s 1.28.9 共享集群（containerd 1.7.13、cgroup v2、内核 5.15.0-91，节点 16C32G，混跑 10+ 个 Java/Go 微服务）。一个核心下单服务（JDK 17，G1，-Xmx4g，Pod requests=2C / limits=4C，memory=4Gi）白天 P99 基线 55ms，过去两周每隔 3~7 小时出现一次 300–800ms 的毛刺（持续 3~5 秒后自动恢复），kubectl describe 无事件、Prometheus 侧 container_cpu_cfs_throttled_seconds_total 无增量、JVM GC 日志（-Xlog:gc*）无 Full GC、应用侧无超时日志，上游网关却能看到 504 零星冒出（约 5~15 笔/次）。

现象（关键细节）

• 毛刺期间 perf sched latency 采样（perf sched record -g -p <pid> -- sleep 10）里出现 2~3 条 sched:schedule 延迟 > 200ms 的记录，被唤醒的线程是 G1 的 Concurrent Mark 线程（不是 GC 线程本身）。
• 毛刺时刻节点上另一个 Pod（Flink JobManager）正在做 checkpoint 写盘（iostat -x 1 显示该节点 await 从 2ms 飙到 48ms，%util 92%）。
• /sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed 在毛刺前后各涨 200–400 页。
• perf stat -e context-migrations 在毛刺窗口里 ctx_migrations 从常态 ~50 涨到 ~2000。

已尝试的排查与结果

1. perf sched latency 抓到了 >200ms 的调度延迟，但分不清是 khugepaged 在后台合并大页导致的缺页中断（khugepaged 走 softirq → 抢占用户态线程），还是邻居 Pod 的 IO 把 block layer 的 CPU 挤掉了，还是 CFS 调度器在毛刺窗口内把线程从核 3 迁到了核 11（跨 NUMA）——三种根因的 perf 签名高度重叠。
2. 临时把 transparent_hugepage 从 always 改成 madvise（echo madvise > /sys/kernel/mm/transparent_hugepage/enabled），观察 48h：毛刺从 ~4 次/天降到 ~1 次/天，没有彻底消失——说明 khugepaged 是因素之一但不是唯一。
3. 给 Flink Pod 加了 io.max（/sys/fs/cgroup/.../io.max 限制 read/write bps），毛刺频率无明显变化——说明 IO 抢占不是主因（或者 io.max 的粒度不够细，只限了 bps 没限 iops）。
4. 用 numactl --cpunodebind=0 --membind=0 手动把下单服务绑到单路 NUMA node 0，毛刺从 ~1 次/天降到 ~1 次/3 天——有效果但没根治，且生产上不能长期绑核（节点是共享的，绑核会浪费另一半 CPU）。

期望得到的答案形态

• 有没有人在线上同时抓过这三类根因（khugepaged / 邻居 IO / CPU 迁移），并给出可区分的观测指标组合？比如：khugepaged 毛刺看 /proc/vmstat 的 compact_stall + khugepaged/pages_collapsed 的增量速率？邻居 IO 看 blkio/throttle.io_service_bytes 而不是 iostat 的 await？CPU 迁移看 perf stat -e context-migrations 还是 numastat 的 numa_hit/numa_miss 比率？
• 如果三类根因叠加（khugepaged 触发缺页 → 缺页处理期间线程被调度器迁移 → 跨 NUMA 访存延迟放大），有没有一个优先级排序：先修哪个收益最大、风险最小？
• 生产共享节点上，transparent_hugepage=madvise 对 Java 服务（G1/ZGC）的长期影响：有没有人做过 1 个月以上的 A/B 对比（madvise vs never vs always），GC 停顿和吞吐分别变化多少？
• io.max 只限 bps 不限 iops 的情况下，Flink checkpoint 写盘的 IO 抢占到底能不能被 io.max 挡住？有没有人试过 io.max + io.weight 组合（比如 io.weight=100 给 Flink、io.weight=1000 给下单服务）？

我倾向的答案方向：先关 khugepaged（echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag）验证一轮，再上 cgroup v2 的 io.weight 做 IO 优先级，最后才是绑核。但我不确定 khugepaged 的 defrag=0 对 G1 的 Concurrent Mark 线程有没有副作用（缺页时不再同步合并 → 大页碎片化 → 长期吞吐下降？），想听听有实战数据的朋友。