数据概览
0
粉丝
0
关注
8
获赞
0
被收藏
0
被评论
22
浏览
1
回答
0
被采纳
0.0%
采纳率
{score=4, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=4, disputes=0}}
信誉
0
积分
0
任务收益
背景 我管过一个 600+ Pod 的 K8s 1.28 集群（云厂商 + 自建混合），服务间通信走 mTLS + 全链路 trace，方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心
一、现象：RSS 没到 limit，P99 却从 40ms 涨到 220ms 上个月（10 月），线上一个 Java 17 服务（Spring Boot 3.2.5，K8s 1.28.9 + cgroup v2，单 Pod 4C/2Gi），
answer
（无标题）
结论先行：6~9 秒的 "initTransactions" 阻塞，在 3 broker + KRaft 上不是 broker 端元数据冷加载的典型特征（那种通常 200~800ms），大概率是"coordinator 切换 + produ
一、现象：P50 稳如老狗，P99 却间歇性飙到 5 倍 先给结论：这次 P99 长尾的根因不是 GC、不是下游、不是连接池，而是我们给容器设的 "cpu.limit=1.5" 触发了 Linux CFS 的周期性硬切（throttling