一次线上 CPU 飙高的完整排查
从告警到定位到修复,记录一次持续四十分钟的性能排查。
告警
下午三点,CPU 使用率从 20% 冲到 95%。接口 P99 从 80 毫秒涨到 4 秒。第一反应是流量突增,但监控面板上的 QPS 曲线平得像条死鱼。
第一步:看进程
dotnet-counters 显示托管堆稳定,GC 时间占比不高——不是内存问题,是纯计算在烧 CPU。线程面板里十几个线程都在跑,没有大量阻塞。
第二步:抓 dump
dotnet-dump collect 抓一份,用 dumpanalyze 看线程栈。几十个线程栈高度一致:都停在一个正则表达式的 Match 调用上。
第三步:看代码
最近上线了个「敏感词过滤」,每次请求都把用户输入过一遍正则。问题出在正则本身:模式里有个嵌套量词,遇到特定长度输入会灾难性回溯。测试环境的数据短,没触发;线上一条两万字的长评直接引爆。
修复
敏感词改用 Trie 树,O(n) 一次遍历。改完 CPU 立刻回落,P99 回到 90 毫秒。
反思
三个教训。一,用户输入的规模永远比测试数据野;二,正则的嵌套量词是性能杀手,code review 要当成危险模式看;三,告警阈值按「同比突增」设,而不是绝对值——这次 QPS 没涨,但 CPU 涨了四倍,绝对值告警太晚。
评论 0
还没有评论,来说两句吧。