pgsql+mysql连接数_PgSQL · 最佳实践 · CPU满问题处理

前言

在数据库运维当中，一个DBA比较常遇到又比较紧急的问题，就是突发的CPU满(CPU利用率达到100%)，导致业务停滞。DBA不一定非常熟悉业务实现逻辑，也不能掌控来自应用的变更或负载变化情况。 所以，遇到CPU满，往往只能从后端数据库开始排查，追溯到具体SQL，最终定位到业务层。这里我们总结下这个问题具体的处理方法。

查看连接数变化

CPU利用率到达100%，首先怀疑，是不是业务高峰活跃连接陡增，而数据库预留的资源不足造成的结果。我们需要查看下，问题发生时，活跃的连接数是否比平时多很多。对于RDS for PG，数据库上的连接数变化，可以从控制台的监控信息中看到。而当前活跃的连接数可以直接连接数据库，使用下列查询语句得到：

select count( * ) from pg_stat_activity where state not like '%idle';

追踪慢SQL

如果活跃连接数的变化处于正常范围，则很大概率可能是当时有性能很差的SQL被大量执行导致。由于RDS有慢SQL日志，我们可以通过这个日志，定位到当时比较耗时的SQL来进一步做分析。但通常问题发生时，整个系统都处于停滞状态，所有SQL都慢下来，当时记录的慢SQL可能非常多，并不容易排查罪魁祸首。这里我们介绍几种在问题发生时，即介入追查慢SQL的方法。

1. 第一种方法是使用pg_stat_statements插件定位慢SQL，步骤如下。

1.1. 如果没有创建这个插件，需要手动创建。我们要利用插件和数据库系统里面的计数信息(如SQL执行时间累积等)，而这些信息是不断累积的࿰