应用执行慢的问题排查路径

在OLTP系统的运维过程当中，可能最“讨厌”的一种场景，就是碰到应用执行慢，因为表象是应用执行慢，或者定位到某条SQL语句执行慢，但根源未必就是数据库，或者不完全就是数据库，例如一次简单的数据检索，可能就会涉及到多个应用、不同的操作系统、网络环境、数据库等资源，可以说环环相扣，毕竟不是“一体机”，任何一个环节的问题，都可能导致相同的现象。

在这个《

《》，就介绍了一种定位问题的思路，可以向程序增加一些断点，无论是要打印到控制台，还是应用日志，通过断点，逐步定位，其中需要注意的一点，就是断点的粒度，如果断点粒度很粗，很可能就无法精确定位。要是复杂一些，打出dump文件，从程序的调用栈，一步步进行判断，是另一种方式，当然这对人员的技术要求更高。

《》，这次碰到的问题，同样值得借鉴，当时整了张图，蜻蜓点水般地梳理下应用层、数据库和网络层的排查路径，

除了技术因素，还有一些非技术因素，可能左右问题的排查，例如：

1. 是否能做到团队间亲密协作，有甲方，有乙方，有DBA，有中间件，有网络，有业务，尤其是临时组成的虚拟团队，信息资源的共享，操作上的互补，都很重要。

2. 是否能清楚地阐述问题，无论是技术人员，还是业务人员，在紧急的情况下，能否言简意赅地表达，提供其他人判断问题的素材，非常重要。

《

北在南方这篇《

有应用反馈发现大量DB慢查，并且日志上还记录了详细的执行时间和SQL语句。接到问题后我们第一时间排查DB发现并没有异常，也没有慢查记录，并且日志中的大部分SQL都能匹配索引，测试执行都在毫秒级。于是开始排查网络是否正常，有没丢包、重传等现象，查询监控数据发现也很正常，然后进行抓包分析发现实际请求处理的速度非常正常，至此可以排除DB问题。

1. 获取连接阶段；

2. 执行查询阶段；

绝大部分情况下获取连接代价非常小，直接就能从连接池获取到，即使需要新建连接代价往往也不大，所以使用时非常容易忽略获取连接这个阶段。什么情况下获取连接会出问题呢？一种情况是建立连接慢，一种是连接池已经耗尽，再对照上面的案例进行排查，依次排除了这两种情况。至 此问题还是一筹莫展，还好高手在场，想到用strace跟踪SQL请求前后干了什么，最后发现记录慢查日志开始和结束之间有写日志操作，这里的写日志是同 步的并且在特定情况下正好触发了另一个问题导致写日志非常慢，并且这个日志操作是封装在底层的，连业务开发都不清楚有这么个操作。至此真相水落石出，最终修复了写日志慢的问题后就不再出现类似的“慢查”了。