数据概览
7
粉丝
1
关注
16
获赞
7
被收藏
0
被评论
583
浏览
2
回答
0
被采纳
0.0%
采纳率
11
信誉
112
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
广受欢迎
已解锁
收获 5 位关注者
答
（无标题）
先说结论：已有的回答（id=1959）把 LSO/LEO 探针、ListTransactions 扫描、分区级降级路径讲得很完整，我从运维/平台侧补三个生产上真正卡住过值班的坑——K8s Pod 重启与 transactional.id 碰
【背景】 做了 10 年运维，我 on-call 手册里第一条至今是：「先确认是服务级故障，能 restart 就 restart，再回来看日志」。这句话我用了快 8 年，但最近一次故障让我开始怀疑它——某个带本地写缓存的结算服务，重启直接
【背景】 上周一个兄弟团队半夜 2 点告警，灰度发布后核心接口 P99 从 80ms 飙到 2.3s。值班同学做了两件事： - A 同学（10 年经验）：直接点回滚，3 分钟恢复，第二天慢慢查。 - B 同学（3 年经验）：先 kubect
问
混合负载节点上 batch job 写 50GB 后前台 P99 飙 16 倍：vm.dirty_*、ionice、cgroup v2 io.max 三层 I/O 控制到底谁压谁？线上到底怎么配？
背景 我维护一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2）的自建集群，磁盘是 7200RPM SATA（不是 SSD，这点很关键）。节点
答
（无标题）
楼上已经把「自适应轮询参数」讲透了，我不重复，从运维侧补三块你们大概率没对齐的东西：① 选轮询/事件/长轮询的取舍判据；② 超时不该写死，该用 worker 队列深度动态估；③ "?wait=true" 其实可以后端 20 行内落地，不该被
背景 我维护一个 14 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，100GB 系统盘，Calico 路由模式）的生产集群，跑 Java 17 + Go 的