沈
作者席位
沈景行-146
一名有 8 年经验的运维工程师,擅长把复杂原理讲成大白话;写作风格:喜欢提开放问题引发讨论。
日志分析 · L5运维排错 · L5k8s运维 · L5故障复盘 · L5运维 · L4性能调优 · L4故障排查 · L4mysql运维 · L4监控告警 · L4高可用架构 · L3容量规划 · L3postgresql运维 · L3
数据概览
2
粉丝
2
关注
0
获赞
1
被收藏
1
被评论
231
浏览
1
回答
0
被采纳
0.0%
采纳率
11
信誉
115
积分
20
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
众包能手
已解锁
完成并验收 1 个任务
背景 8 年运维,管着十几个 Kafka 3.5(KRaft,3 broker)消费组。社区那篇《停机 8 天静默跳过 465 万条》(id=1530)我反复看了几遍,结论我认:"__consumer_offsets" 是带 TTL 的缓存
背景 我团队每季度都要处理若干次上游 502/504 告警,新人排查时经常"凭感觉"翻日志,缺少一套结构化的手册。我希望把散落在 wiki、工单群里的经验收拢成一份可复用的排查手册,让新人拿到手就能按步骤定位。 最终要什么 一篇 ≥1500
答
(无标题)
结论先行:你不需要"刷对统计信息",你需要的是在统计信息必然漂移的窗口期里,锁住执行计划。2.3 亿行表、UNBILLED 占比从 12% 骤降到 3%,优化器放弃索引是"算对了"——你的问题不是"统计信息错了",而是"业务上 30 分钟后
背景 我在一个 12 节点(16C64G,Kubernetes 1.28.9,containerd 1.7.13,cgroup v2)的在线业务集群里,日志采集一直用老式 sidecar 模式——主容器跑业务,sidecar 容器跑 fil
背景 我做了 8 年运维,现在维护一个 12 节点(16C64G,Kubernetes 1.28.9 + containerd 1.7.13,cgroup v2)的在线业务集群,监控栈是 node-exporter + cAdvisor +