如何分析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的比例也会比较高。
