遇到类似问题,大家都是如何排查的?
1
yannxia 2023-02-09 10:54:20 +08:00 1
最简单的方法,加点 Debug 日志,尤其在和 IO 相关的(数据库 etc) 判断是不是因为数据库查询导致的
基于上面扩展的就介入一些动态分析的工具,都差不多,逐步判断出范围 人肉点的,看看查询的接口条件有没有什么共性,然后再思考有什么可能导致,看经验判断。 |
2
dqzcwxb 2023-02-09 11:53:25 +08:00
如果是 java,用 arthas trace 定位耗时方法或代码再对症下药
其他语言,用二分法打 log 逐步定位或者按自己想法打 log 逐步定位 |
3
anonymousar 2023-02-09 12:04:59 +08:00
简单点的就分段加 timer 。
复杂的可以用 systemtap 。 |
4
opengps 2023-02-09 12:13:43 +08:00 1
一般来说重点都在磁盘环节(软件层往往是数据库访问环节)
然后是代码逻辑问题,着重看那些需要带重试等待的 |
5
oneisall8955 2023-02-09 12:53:17 +08:00 via Android
加日志,或 sky walking 类似看各个环节耗时
|
6
linqiu919 2023-02-09 16:49:54 +08:00 via iPhone
skywalking 链路追踪
|
7
MidGap 2023-02-09 16:55:26 +08:00
上链路追踪是比较正式的,或者就分段打印耗时
|
8
wtfedc OP 感谢各位,找到是数据同步时候,数据库 IO 打满的问题
|
9
OliverDD 2023-02-10 00:51:37 +08:00 via iPhone
这种耗时长尾先排查 IO ,排队
|