典型问题 同机混部下，关键服务线程会被后台任务、ksoftirqd 和内核 housekeeping 干扰，导致 p99 抖动长期无法收敛。 隔离手段 通过 cpuset 为关键进程绑定独占核心。 将中断亲和性避开关键核心。 把系统 housekeeping 任务集中到专用核。 验证方法 对比隔离前后 p99/p999。 观察调度切换次数与 run queue 长度。 结合 perf 看 cache miss 与上下文切换变化。 小结 CPU 隔离不是“调个参数”，而是资源编排策略。把关键路径从系统噪声里解耦，低延迟目标才有实现基础。
为什么要持续 Profiling 离线抓火焰图只能解释“当下问题”，无法覆盖版本演进中的渐进回归。持续 profiling 能提供趋势视角。 落地关键 采样频率按服务等级分层，避免全局高频。 只保留聚合后的符号栈，降低存储压力。 结合版本号维度做回归对比。 噪声治理 排除短命批处理进程。 对 JIT 语言补齐符号映射。 过滤启动期冷缓存阶段样本。 常见风险 盲目提高采样率导致 CPU 额外开销。 内核版本不一致引发采样偏差。 只看 Top 函数，忽视调用链变化。 小结 持续 profiling 不是“多收集”，而是“低扰动、可对比、可解释”的长期性能体检体系。
症状识别 业务负载稳定，但 RSS 只涨不降。 堆分析看不到明显泄漏对象。 进程重启后内存瞬间回落。 为什么会碎片化 多线程下不同 size class 高频分配释放。 短命与长命对象混放。 大量临时 buffer 导致 arena 难回收。 治理路径 分离对象生命周期：短命池与长命池分开。 统一热点对象尺寸，减少跨 class 抖动。 评估 jemalloc/tcmalloc 与默认 allocator 差异。 线上指标建议 allocated_bytes active_bytes resident_bytes fragmentation_ratio = resident / active 风险点 只看进程总内存，不看分配器内部统计。 盲目手写内存池，忽略线程本地缓存竞争。 回收策略和 NUMA 绑定冲突。 小结 碎片治理是系统工程：对象模型、分配器、线程调度、NUMA 拓扑都要协同。先观测后改造，收益才稳定。
问题不在快，而在失控 很多 io_uring 服务在压测里吞吐漂亮，线上却出现尾延迟飙升。根因通常是提交队列无限推进，完成队列消费跟不上。 背压触发条件 SQ ring 使用率超过 80%。 CQ backlog 持续增长。 业务层处理耗时超过 IO 完成速率。 建议的三层背压 提交层：限制 in-flight 请求上限。 协程层：队列超阈值时暂停新任务调度。 入口层：对上游返回 retry-after 或降级响应。 伪代码 if (inflight > max_inflight || cq_backlog > cq_limit) { pause_accept(); shed_low_priority(); } while (io_uring_peek_cqe(&ring, &cqe) == 0) { handle_cqe(cqe); io_uring_cqe_seen(&ring, cqe); } 关键指标 submit_to_complete_latency cq_backlog inflight shed_count 小结 io_uring 的上限很高，但系统稳定性的上限由背压机制决定。先把“慢下来也不爆炸”做对，再追求“快”。
先说结论 多数业务服务里，epoll 依然是稳妥选择。io_uring 在某些高并发 IO 场景能更快，但复杂度也更高。 epoll 的优势 生态成熟，排障资料多 编程模型稳定 与现有网络库兼容性好 对于大部分 API 服务，epoll 足够用。 io_uring 的价值点 减少系统调用次数 提升批量提交与完成处理效率 在特定负载下降低延迟 但它要求你理解提交队列、完成队列、内核版本差异等细节。 选型建议 先压测当前 epoll 方案，定位真实瓶颈 若瓶颈明确在 IO 提交/完成路径，再评估 io_uring 预留回退方案，避免一次性全量切换 团队视角 技术选型不只看 benchmark，还要看： 团队掌握程度 线上问题可定位性 长期维护成本 小结 新能力值得关注，但架构决策应以稳定收益为中心。对大多数团队来说，逐步引入比激进替换更现实。
背景 裸重启进程很简单，但线上会带来短暂不可用。优雅重启的目标是： 停止接收新连接 等待在途请求处理完 平滑切换到新进程 Go 侧的退出处理 srv := &http.Server{Addr: ":8080", Handler: mux} go func() { if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed { log.Fatal(err) } }() sigCh := make(chan os.Signal, 1) signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT) <-sigCh ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) defer cancel() _ = srv.Shutdown(ctx) Shutdown 会先关闭监听，再等待连接收尾。 systemd 关键配置 [Service] ExecStart=/opt/app/server Restart=always RestartSec=2 TimeoutStopSec=20 KillSignal=SIGTERM KillSignal=SIGTERM 给应用机会走优雅退出逻辑 TimeoutStopSec 要大于应用 Shutdown 超时 发布建议 先在网关层摘流量 再重启实例 观察错误率与连接数回落 小结 优雅重启不是一个函数调用，而是应用与进程管理器协同设计。把退出路径做好，发布风险会明显下降。