PG数据库服务器的CPU使用率突然升高该怎么分析
发布时间：2023-02-14 13:17:46 所属栏目：大数据 来源：互联网
导读：如果遇到数据库服务器CPU使用率突然大幅增高或者过高的问题，不论是哪种数据库，我们都要首先查看一下操作系统上有没有非数据库的进程使用了过高的CPU资源，这个使用TOP工具就可以实现了，不要因为SWAP、大规模CACHE DROP等操作引发的CPU使用率突增让数据库
|
如果遇到数据库服务器CPU使用率突然大幅增高或者过高的问题，不论是哪种数据库，我们都要首先查看一下操作系统上有没有非数据库的进程使用了过高的CPU资源，这个使用TOP工具就可以实现了，不要因为SWAP、大规模CACHE DROP等操作引发的CPU使用率突增让数据库来背锅了，搞的你分析了一大圈，发现完全和数据库无关。几年前我遇到过一个案例，一个用户让我帮助分析他们的CPU怎么突然100%了，我也是没注意这些问题，直接在数据库里找问题，最后分析了一大圈，发现负载啥的都和前一天没啥区别，就是CPU使用率多了30%。后来实在没招了，用TOP看了一下，发现了一个异常的进程，居然在做科学计算，这个进程正好消耗了30%多的CPU资源。最后客户那边确认了一下，十分不好意思的说，是一个几年前设置的一个crontab任务忘了关闭了，才导致了今天的问题。几年前，他们搞数据库合库，只要CPU使用率在一个月中没有一天业务高峰期超过35%的数据库，就必须合并到其他数据库中，从而节约资源。他们干了几套系统后觉得太辛苦了，部门领导就想了个招，在月底业务高峰期的时候，让一个科学计算的任务跑上几个小时，让符合合并的数据库变少一点，大家也少干点活。没想到这台服务器上的任务忘了关了，而这些年这套系统的数据量越来越大，负载也越来越高了，没想到这个月底业务很忙，居然把CPU跑爆掉了。 另外如果在一台物理机上跑多个数据库实例，我们就不能只看一个数据库的情况了，而是要看多个数据库的总体负载。 首先，也是可能性最大的方面，出现大查询或者较高并发量的SQL执行计划变坏：如果数据库中的某个查询或某组查询的复杂度增加，则可能导致CPU使用率的增加;一条常见SQL的执行计划错误也会导致执行开销增加，虽然单条SQL的延时仍然在业务能够忍受的范围内，但是总体CPU消耗会大幅增大，如果CPU资源出现瓶颈，那么系统整体性能都会严重下降。 第二，出现严重的资源竞争：如果多个连接或会话同时请求大量的数据，则可能会产生资源竞争，甚至引发spinlock等自旋锁争用，从而导致CPU使用率的增加，分析这方面的原因通过PG的等待事件进行分析是比较有效的。 第三，索引缺失导致的SQL执行计划不够优化：如果数据库表缺少索引，则查询操作将需要扫描整个表，从而导致CPU使用率的增加。 第四，数据库维护任务：如果数据库正在进行大型的维护任务(例如VACUUM，ANALYZE等)，则可能导致CPU使用率的增加。 导致CPU使用率突然增高的可能性还有很多，不过对于PG数据库来说，大部分此类问题都是大并发SQL或者SQL执行计划变坏引发，加强SQL问题的监控一般来说能解决大多数PG的CPU问题。今天时间有限，仅仅讨论了一下常见的故障场景。不断积累这方面的知识库是企业和DBA应该做的事情，如果能够通过社区共同积累此类问题，那就会事半功倍。也希望大家有兴趣加入我们的DBAIOPS社区，共同来做这项工作。这项工作的成果会发布在D-SMART社区版中，我们也会定期通过文章汇报汇总的情况。 （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
