前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >问题定位的思考

问题定位的思考

作者头像
bisal
发布2021-12-14 19:59:47
1.3K0
发布2021-12-14 19:59:47
举报
文章被收录于专栏:bisal的个人杂货铺

领导同事都曾问到过,如果出现一个数据库问题,或者应用的问题,应该怎么快速定位该问题?

这个问题很开放,同一个故障现象,可能不同人都会有不同的排查路径,但是殊途同归,能定位问题,解决问题,这才是关键,区别就在速度和准确性,有人1分钟定位,有人1小时定位,都可以解决,有人能找到问题的根因,有人歪打正着解决了问题,但是问题根因不太对,当然每次排障的过程,都是一次经验的积累。

不同的故障现象,排查路径上可能有所不同,但无论是应用,还是中间件,或者是数据库,有些套路,还是相通的,例如日志,包括不仅限于应用日志、数据库日志、中间件日志、操作系统日志等;操作系统的负载,包括不仅限于CPU、内存、磁盘(文件空间、inode、IO读写等)、网络等。其中不太稳定的,就是应用日志,因为其他的信息,基本都是成熟的,例如数据库日志,记录的类型、内容,都是经过实践的,或者是通过数据展示的,例如CPU idle,都是客观的。应用日志,可能取决于开发人员记录日志的习惯,即使有日志规范,很多内容上、关键节点的信息,还是依靠人的主观多些。当然即使是成熟客观的信息,还得需要我们来解读,这可能给我们定位问题提出了更高的要求,你得看懂日志中记录的信息,知道什么是关键,还得知道这些统计数据代表了什么,相互之间的关联,又可以说明什么。这些可能都不是靠一本葵花宝典能解决的。

例如以前我们某个应用出现问题了,如果是处理异常,可能先找的就是应用日志,根据报错信息,找到日志位置,根据上下文判断能不能定位问题,这就取决于日志记录的水平了。其实这种有具体报错的问题,还是有很多线索可用的,最难的可能就是那些很隐秘的问题,例如应用执行慢,如果应用日志记录了具体操作的步骤和执行时间,我们就可能定位到某个逻辑,再判断是程序处理的问题,磁盘读写的问题,网络传输的问题,还是数据库交互的问题,进而到这些组件中再寻找线索。但是如果应用日志记录的很有限(很可能是常事儿),只能根据业务表象来倒推程序的逻辑,这里可以将处理流程拆成更小的粒度,例如读数据库、读缓存、读文件、应用逻辑处理、写文件、写数据库等,如果应用慢,每个环节都值得怀疑,我们就需要逐一进行排除。例如读写文件,我们可以看下磁盘当前的读写性能、存储空间等。例如数据库,我们可以通过SQL执行计划、AWR、ASH、动态性能视图等,看下数据库当前的运行情况。例如网络,我们可以看下连接端口的速度、丢包的情况等。

历史文章中,《一次Oracle bug的故障排查过程思考》,表象是应用执行慢了,再推一下,某条SQL执行慢了,导致应用hang了,但根源是一个Oracle的bug,同时应用起到了推波助澜的作用,足以看出一个“慢”的问题排查,有时候挖掘起来,确实不容易的。

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

数据库连接池配置参考》则以druid作为示例,介绍了连接池的一些配置,换句话说,连接池配置异常,是导致应用慢的原因之一。

北在南方这篇《数据库连接池配置(案例及排查指南)》,提供了个非常经典的“数据库慢查的排查过程”,在排查思路上,值得学习,

有应用反馈发现大量DB慢查,并且日志上还记录了详细的执行时间和SQL语句。接到问题后我们第一时间排查DB发现并没有异常,也没有慢查记录,并且日志中的大部分SQL都能匹配索引,测试执行都在毫秒级。于是开始排查网络是否正常,有没丢包、重传等现象,查询监控数据发现也很正常,然后进行抓包分析发现实际请求处理的速度非常正常,至此可以排除DB问题。 于是再深入分析,查询DB其实可分为两个阶段: 1. 获取连接阶段; 2. 执行查询阶段; 绝大部分情况下获取连接代价非常小,直接就能从连接池获取到,即使需要新建连接代价往往也不大,所以使用时非常容易忽略获取连接这个阶段。什么情况下获取连接会出问题呢?一种情况是建立连接慢,一种是连接池已经耗尽,再对照上面的案例进行排查,依次排除了这两种情况。至此问题还是一筹莫展,还好高手在场,想到用strace跟踪SQL请求前后干了什么,最后发现记录慢查日志开始和结束之间有写日志操作,这里的写日志是同步的并且在特定情况下正好触发了另一个问题导致写日志非常慢,并且这个日志操作是封装在底层的,连业务开发都不清楚有这么个操作。至此真相水落石出,最终修复了写日志慢的问题后就不再出现类似的“慢查”了。

一次惊心动魄的问题排查》,这次碰到的问题,同样值得借鉴,当时整了张图,蜻蜓点水般地梳理下应用层、数据库和网络层的排查路径。借此机会,补充一些环节,

同样的问题现象,原因可能不同,因此,对基础原理的理解和实践,对日常问题处理的积累,对相关知识点的融会贯通,都是提高我们定位和解决问题能力的重要途径。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021/12/13 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档