PostgreSQL/PPAS CPU使用率高的排查及解决办法

PostgreSQL/PPAS CPU使用率高的排查及解决办法

问题描述

RDS for PostgreSQL/PPAS使用过程中，可能会遇到CPU使用率过高甚至达到100%的情况。本文将介绍造成该状况的常见原因以及解决方法，并通过CPU使用率为100%的典型场景，来分析引起该状况的排查及其相应的解决方案。

解决方案

SQL 优化，增加缓存、索引、SQL拆分、优化SQL减少数据库计算量放到程序计算

服务器参数调优，数据库参数调优，Tomcat参数调优

Kibana + Elasticsearch 收集Tomcat日志，定义日志级别 error -> warn -> info -> debug -> trace

Redis key内存使用 RDR

SQL 日志分析工具 pgBadger

目前在PostgreSQL 中支持：

• Seq Scan，顺序扫描

• Index Scan，基于索引扫描，但不只是返回索引列的值

• IndexOnly Scan，基于索引扫描，并且只返回索引列的值，简称为覆盖索引

• BitmapIndex Scan，利用Bitmap 结构扫描

• BitmapHeap Scan，把BitmapIndex Scan 返回的Bitmap 结构转换为元组结构

• Tid Scan，用于扫描一个元组TID 数组

• Subquery Scan，扫描一个子查询

• Function Scan，处理含有函数的扫描

• TableFunc Scan，处理tablefunc 相关的扫描

• Values Scan，用于扫描Values 链表的扫描

• Cte Scan，用于扫描WITH 字句的结果集

• NamedTuplestore Scan，用于某些命名的结果集的扫描

• WorkTable Scan，用于扫描Recursive Union 的中间数据

• Foreign Scan，用于外键扫描

• Custom Scan，用于用户自定义的扫描

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

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

追踪慢SQL

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

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

   1. 如果没有pg_stat_statements插件，需要先手动创建。要利用插件和数据库系统里面的计数信息（如SQL执行时间累积等），而这些信息是不断累积的，包含了历史信息。为了更方便的排查当前的CPU过高问题，要先使用如下命令重置计数器。

      create extension pg_stat_statements;
      select pg_stat_reset();
      select pg_stat_statements_reset();

   2. 等待一段时间（例如1分钟），使计数器积累足够的信息。

   3. 参考如下命令查询最耗时的SQL，一般就是导致问题的直接原因。

      select * from pg_stat_statements order by total_time desc limit 5;
      ​
      SELECT query,calls,total_time,(total_time / calls) avage,ROWS FROM pg_stat_statements WHERE calls > 1000 AND (total_time / calls > 1000) ORDER BY avage DESC LIMIT 10;

   4. 参考如下SQL语句，查询读取Buffer次数最多的SQL，这些SQL可能由于所查询的数据没有索引，而导致了过多的Buffer读，也同时大量消耗了CPU。

      select * from pg_stat_statements order by shared_blks_hit + shared_blks_read desc limit 5;

2. 第二种方法是直接通过pg_stat_activity视图，参考如下查询SQL语句，查看当前长时间执行，一直不结束的SQL。这些SQL也可能造成CPU过高。

   select datname,
          usename,
          client_addr,
          application_name,
          state,
          backend_start,
          xact_start,
          xact_stay,
          query_start,
          query_stay,
          replace(query, chr(10), ' ') as query
   from
     (select pgsa.datname as datname,
             pgsa.usename as usename,
             pgsa.client_addr client_addr,
             pgsa.application_name as application_name,
             pgsa.state as state,
             pgsa.backend_start as backend_start,
             pgsa.xact_start as xact_start,
             extract(epoch
                     from (now() - pgsa.xact_start)) as xact_stay,
             pgsa.query_start as query_start,
             extract(epoch
                     from (now() - pgsa.query_start)) as query_stay,
             pgsa.query as query
      from pg_stat_activity as pgsa
      where pgsa.state != 'idle'
        and pgsa.state != 'idle in transaction'
        and pgsa.state != 'idle in transaction (aborted)') idleconnections
   order by query_stay desc
   limit 5;

3. 第3种方法是从数据表上表扫描（Table Scan）的信息开始查起，查找缺失索引的表。数据表如果缺失索引，大部分热数据又都在内存时（例如内存8G，热数据6G），此时数据库只能使用表扫描，并需要处理已在内存中的大量无关记录，导致耗费大量CPU。特别是对于表记录数超过100的表，一次表扫描占用大量CPU（基本把一个CPU占满）和多个连接并发（例如上百连接）。

   1. 参考如下SQL语句，查出使用表扫描最多的表。

      select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

   2. 参考如下SQL语句，查询当前正在运行的访问到上述表的慢查询。

      select * from pg_stat_activity where query ilike '%<table name>%' and query_start - now() > interval '10 seconds';

      注：也可以通过pg_stat_statements插件定位涉及到这些表的查询，如下所示。

      select * from pg_stat_statements where query ilike '%<table>%'order by shared_blks_hit+shared_blks_read desc limit 3;

处理慢SQL

对于上面的方法查出来的慢SQL，如下所示，首先需要做的是结束掉它们，使业务先恢复。

select pg_cancel_backend(pid) from pg_stat_activity where  query like '%<query text>%' and pid != pg_backend_pid();
select pg_terminate_backend(pid) from pg_stat_activity where  query like '%<query text>%' and pid != pg_backend_pid();

如果这些SQL确实是业务上必需的，则需要对他们做如下优化。

1. 对查询涉及的表，执行

   ANALYZE [$Table]
   

   或

   VACUUM ANZLYZE [$Table]
   

   语句，更新表的统计信息，使查询计划更准确。为避免对业务影响，最好在业务低峰执行。

   注：[$Table]为查询涉及的表。

2. 选择一条如下SQL语句执行，查看SQL的执行计划，第一条SQL语句不会实际执行SQL语句，第二条SQL语句会实际执行而且能得到详细的执行信息，对其中的Table Scan涉及的表，建立索引。

   explain [$Query_Text]explain (buffers true, analyze true, verbose true) [$Query_Text]
   

   注：[$Query_Text]为SQL文件或语句。

3. 重新编写SQL语句，去除掉不必要的子查询、改写UNION ALL、使用JOIN CLAUSE固定连接顺序等，都是进一步深度优化SQL语句的手段，这里不再深入说明。

​​​​​​​