Daily Study

更新: 1/9/2026 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

出现一个服务很慢，排查过程

遵循 USE 方法（Utilization 利用率, Saturation 饱和度, Errors 错误）的逻辑，按照 宏观（系统） -> 微观（进程） -> 深度（代码/内核） 的顺序进行

宏观快速定位瓶颈：

• 查负载 (Load Average)：命令：uptime 或 top。看 load average（1分钟/5分钟/15分钟）如果 Load > CPU 核数，说明系统过载
• 查 CPU (利用率)：命令：top。
  • us (User)：用户态高？检查业务逻辑是否在做复杂运算（序列化、加密、压缩）。
  • sy (System)：内核态高？检查是否有过多的系统调用（上下文切换、锁竞争）。
  • wa (iowait)：等待 I/O？如果有值，说明磁盘撑不住了。
  • si (Softirq)：软中断？网卡流量是不是太大了，把 CPU 打满了。
• 查内存 (Memory)：free -h, vmstat 1。是否使用了 Swap？一旦服务开始用 Swap，性能会断崖式下跌。
• 查磁盘 I/O (饱和度)：iostat -xz 1。%util：如果接近 100%，说明磁盘忙死了。还可以看平均等待时间
• 查网络(Network)：netstat -s带宽是否跑满。是否有TCP重传，如果有大量重传，说明网络丢包严重，直接导致服务器响应慢。

微观分析：锁定进程行为：

• 进程级分析：top -Hp <pid>
• 系统调用追踪：strace -p <pid> -T -tt。查看进程在做什么系统调用，以及每个调用花了多久。strace 会严重拖慢进程执行，生产环境慎用（或者使用 perf/eBPF 替代）
  • 是否有大量的 futex（锁竞争）。
  • 是否有 read/write 耗时极长（IO 慢）。
  • 是否有 epoll_wait（在等待网络请求，说明没事干）
• 抓包分析：tcpdump -i eth0 tcp port 80 -w capture.pcap，打开

代码级深度排查：

• Go Pprof，生成火焰图来分析
• Trace工具，go tool trace，查看Goroutine调度情况

具体回答：

• 先看宏观资源（USE 方法）：使用 top, free, iostat 快速判断是 CPU、内存、IO 还是网络瓶颈。特别是要看有没有发生 Swap 或者 iowait 过高。
• 再看微观进程：如果定位到具体进程，我会用 top -Hp 看线程状态。如果是 Go 服务，我会立刻采集 Pprof（CPU profile 和 Trace），看火焰图是卡在业务逻辑计算，还是卡在 GC / 锁竞争上。
• 分析外部依赖：如果自身资源正常，大概率是下游（DB/Redis/第三方API）慢。我会检查应用日志中的慢查询日志，或者通过 Tracing 系统（如 Jaeger）看链路耗时。
• 兜底大招（eBPF）：如果常规手段查不出原因（例如偶发性抖动），我会利用 eBPF 工具（如 offcputime）在内核层分析进程被调度出去的原因，精准定位是内核锁还是磁盘毛刺，且不影响生产性能。