国产集中式数据库运维诊断通用办法_

从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过高，那么大概率是存储出问题了。