PG数据库服务器的CPU使用率突然升高该如何分析

​现在基于PG或者脱胎于PG的国产数据库越来越多，再加上PG社区版用户也在快速增长，因此多学点PG的知识对于DBA今后的转型来说，还是挺有用的，因此这几天我们多讨论一些PG相关的问题。昨天我们讨论了PG IO优化方面的问题，今天我们就来讨论一个核CPU有关的问题。今天的议题是，如果PG数据库服务器的CPU使用率突然升高，我们应该从哪几个方面去分析。

如果遇到数据库服务器CPU使用率突然大幅增高或者过高的问题，不论是哪种数据库，我们都要首先查看一下操作系统上有没有非数据库的进程使用了过高的CPU资源，这个使用TOP工具就可以实现了，不要因为SWAP、大规模CACHE DROP等操作引发的CPU使用率突增让数据库来背锅了，搞的你分析了一大圈，发现完全和数据库无关。几年前我遇到过一个案例，一个用户让我帮助分析他们的CPU怎么突然100%了，我也是没注意这些问题，直接在数据库里找问题，最后分析了一大圈，发现负载啥的都和前一天没啥区别，就是CPU使用率多了30%。后来实在没招了，用TOP看了一下，发现了一个异常的进程，居然在做科学计算，这个进程正好消耗了30%多的CPU资源。最后客户那边确认了一下，十分不好意思的说，是一个几年前设置的一个crontab任务忘了关闭了，才导致了今天的问题。几年前，他们搞数据库合库，只要CPU使用率在一个月中没有一天业务高峰期超过35%的数据库，就必须合并到其他数据库中，从而节约资源。他们干了几套系统后觉得太辛苦了，部门领导就想了个招，在月底业务高峰期的时候，让一个科学计算的任务跑上几个小时，让符合合并的数据库变少一点，大家也少干点活。没想到这台服务器上的任务忘了关了，而这些年这套系统的数据量越来越大，负载也越来越高了，没想到这个月底业务很忙，居然把CPU跑爆掉了。

另外如果在一台物理机上跑多个数据库实例，我们就不能只看一个数据库的情况了，而是要看多个数据库的总体负载。

除此之外，如果排除了这些问题，单单来讨论PG数据库，如果真的是PG数据库引发了CPU突然增加，我们应该如何去分析呢？今天我简单的罗列了一些常用场景，遇到问题的时候，DBA可以一条条的进行排除。

首先，也是可能性最大的方面，出现大查询或者较高并发量的SQL执行计划变坏：如果数据库中的某个查询或某组查询的复杂度增加，则可能导致CPU使用率的增加；一条常见SQL的执行计划错误也会导致执行开销增加，虽然单条SQL的延时仍然在业务能够忍受的范围内，但是总体CPU消耗会大幅增大，如果CPU资源出现瓶颈，那么系统整体性能都会严重下降。

第二，出现严重的资源竞争：如果多个连接或会话同时请求大量的数据，则可能会产生资源竞争，甚至引发spinlock等自旋锁争用，从而导致CPU使用率的增加，分析这方面的原因通过PG的等待事件进行分析是比较有效的。

第三，索引缺失导致的SQL执行计划不够优化：如果数据库表缺少索引，则查询操作将需要扫描整个表，从而导致CPU使用率的增加。

第四，磁盘IO瓶颈：如果数据库的磁盘IO不能满足需求，则可能导致CPU使用率的增加。这一点可能会让朋友们感到诧异，IO瓶颈的时候，会话不都在等待IO吗？怎么会引发CPU的问题呢？PostgreSQL 使用同步阻塞 IO（Buffered IO），同步阻塞 IO 意味着在完成 IO 操作之前，PostgreSQL 会阻塞等待 IO 操作的完成。当数据库服务器需要读写磁盘数据时，它会阻塞其他操作，直到 IO 操作完成。在这种情况下，IO延时会比平时高很多，CPU使用率中的IOWAIT的比例也会比较高。

第五，数据库维护任务：如果数据库正在进行大型的维护任务（例如VACUUM，ANALYZE等），则可能导致CPU使用率的增加。

第六，缓冲污染：这种情况出现几率较低，而且出现后也很难被发现。当缓存中的数据大多数是很少使用的数据时，就会出现缓存污染，导致频繁的缓存未命中，导致 CPU 利用率增加。当缓存污染发生时，CPU 会花更多的时间从存储中读取数据，而花更少的时间从缓存中执行指令。 这会导致整体系统性能下降和 CPU 使用率增加。对于PG这种shared_buffers配置占OS比例较低，采用DOUBLE BUFFER机制的数据库系统，出现缓冲污染的几率远大于Oracle等数据库。缓冲污染一旦产生，在SQL执行计划不发生变化的情况下，也会产生较为严重的性能下降，因此需要避免。对于经常出现类似问题的数据库，可以通过使用各种预热插件来不断预热热数据，从而防止缓冲污染。

第七，某张经常全表扫码的小表因为膨胀而突然变大：这种情况出现概率较低，不过也比较容易出现，如果某张表关闭了VACUUM并且常有UPDATE操作，那么经过一段时间积累，可能引发性能问题。

导致CPU使用率突然增高的可能性还有很多，不过对于PG数据库来说，大部分此类问题都是大并发SQL或者SQL执行计划变坏引发，加强SQL问题的监控一般来说能解决大多数PG的CPU问题。今天时间有限，仅仅讨论了一下常见的故障场景。不断积累这方面的知识库是企业和DBA应该做的事情，如果能够通过社区共同积累此类问题，那就会事半功倍。也希望大家有兴趣加入我们的DBAIOPS社区，共同来做这项工作。这项工作的成果会发布在D-SMART社区版中，我们也会定期通过文章汇报汇总的情况。​