摘要:对于大多数国产数据库而言,除了数据库本身存在的问题或者BUG等,大多数的问题还是可以通过一些通用的手段来进行分析的。这两天老白花了点时间梳理了一张思维导图。下面我来简单介绍一下这张导图。
从Oracle等数据库迁移到国产数据库上来,大家可能还有些不适应。如果遇到问题该怎么办?如何去做分析,如何定位根因呢?
对于大多数国产数据库而言,除了数据库本身存在的问题或者BUG等,大多数的问题还是可以通过一些通用的手段来进行分析的。这两天老白花了点时间梳理了一张思维导图。下面我来简单介绍一下这张导图。
分析的第一步肯定是查看日志,数据库日志永远是故障定位最为重要的环节,因此查看数据库日志是一切故障、性能分析的起点。有些日志问题可能很快就能帮你定位数据库故障,不过有时候可能遇到了BUG,或者你根本看不懂国产数据库的日志(某些国产分布式数据库的日志是极难阅读的),如果你的数据库厂商提供比较及时的服务,将日志采集好发送给国产数据库原厂售后人员是十分关键的。
有些时候遇到数据库性能问题,也可以开启慢日志来抓取相关SQL,不过开启慢日志会带来一定的开销,因此只能在分析问题的短时间内开启。
如果数据库日志没有发现问题,那么下一步就要做操作系统日志的分析。如果OS日志没有发现问题,那么下一步就是做OS资源分析。
一般情况下OS资源使用率应该处于较为正常的范围,如果有OS监控系统,能够看到历史数据,通过历史数据的比对就更容易发现问题了。在OS资源分析的时候,更加注重于发现“异常”,而不是看绝对值。
对于内存,不能仅看内存使用率,内存使用率在LINUX系统中是一个指向性不强的指标。内存不可用率或者内存可用率的指向性更强。发现内存问题的另外一个方法是看系统中是否存在严重的换页。如果内存资源存在问题,出现了换页或者OOM KILLER,那么可以通过分析TOP 内存占用进程来找到可能存在的内存杀手。仔细查看MEMINFO文件,找出其中的问题关键是必须要做的事情。是CACHE占用内存过多了,还是没有启用大页,导致页表的内存占用过大。亦或是透明大页导致的内存碎片化,引发了内存的性能问题?
IO问题十分典型的包括IO吞吐量过大、IO延时超标等。如果IO延时过大,那么就要分析后端存储是否存在问题,多路径是否出现过切换。这时候有个检查项是容易被忽视的,那就是异常进程分析。如果D状态的进程很多,而且长时间不消除,那么大概率是存储系统的哪个地方出问题了。
CPU的情况比较复杂,不能仅看CPU使用率比较高就认定CPU引发了问题,还要看r队列的大小(LINUX中称为load,负载),如果R长期大于CPU线程数的2倍,那么CPU可能真的有瓶颈了,否则只能说系统负载较高,但是还不一定能引发性能问题。如果USR高,说明应用可能是CPU消耗过大的元凶,分析会话和TOP SQL就可以了。如果SYS过高,那么就比较复杂了。SPINLOCK,换页,内存碎片,存储系统故障,网络故障,数据库闩锁争用严重,达梦DSC集群争用等都可能导致SYS CPU使用率异常(这里说的异常不一定是SYS CPU特别高,当CPU使用率总体不高,SYS占比过高的时候,也可能已经出现了系统性能异常了)。如果WIO过高,那么大概率是存储出问题了。
如果OS资源没有发现什么问题,那么我们就必须去从数据库的角度找问题了。这方面也有一些数据库通用的诊断方法。首先如果数据库支持等待事件,而且等待事件相对是准确的,那么通过等待事件可以看出一些端倪。如果等待事件无法发现问题,那么接下来去看长事务和锁就可以了。
如果这方面没有问题,那么进一步做会话异常分析,大概率会发现问题。这里要注意的一个是会话执行SQL数量最多的SQL是最需要关注的也是容易被忽视的问题。会话的数量是否异常,活跃会话数量是否异常,会话来自的服务器分布情况是否异常,会话来自的应用程序模块是否异常等等,都是判别会话是否异常的重要手段。
如果你的系统存在历史会话信息(类似于Oracle ASH),那么恭喜你,你拥有了更为强大的分析手段。将数据库会话分析的方法应用于历史会话分析上,会有更加好的效果。
基于我今天介绍的方案,针对一个集中式国产数据库,哪怕你以前没有怎么接触过,也可以轻松的进行故障、性能分析了。这套方案,基本上可以覆盖80%以上的常见问题。大家如果有兴趣可以在遇到问题的时候试一试。分布式数据库的诊断方法类似,不过有更复杂的逻辑,等我有空的时候再画一张图吧。
来源:IT168企业级