【巡检问题分析与最佳实践】RDS PostgreSQL CPU高问题-阿里云开发者社区

开发者社区> 阿里云数据库> 正文
登录阅读全文

【巡检问题分析与最佳实践】RDS PostgreSQL CPU高问题

简介: 当RDS PostgreSQL实例的CPU使用率持续较高时,很容易导致数据库访问卡慢的情况,例如一些很简单的查询请求的响应时间也会很久甚至超时失败。

往期分享

RDS MySQL 小版本升级最佳实践

RDS MySQL 实例空间问题

RDS MySQL 内存使用问题

RDS MySQL 活跃线程数高问题

RDS MySQL 慢SQL问题

RDS MySQL 实例IO高问题

概述

CPU使用率过高问题是RDS PG用户遇到的性能问题中较常见的一类。当RDS SQL Server实例的CPU使用率持续较高时,很容易导致数据库访问卡慢的情况,例如一些很简单的查询请求的响应时间也会很久甚至超时失败。

资源监控

在RDS控制台的“监控与报警”页中的“标准监控”->“资源监控”下,可以查看指定时间段内实例的CPU使用率信息。

image.png

对于RDS PG来说,CPU使用率持续大于80%以上,通常表明系统处于高负载的情况,并且很可能存在较严重的性能问题。

CPU基本概念

  • CPU使用率,CPU使用率指的是CPU执行工作时间的比例,包含了所有符合条件的活动的时钟周期,比如停滞等待IO而导致较高的使用率,CPU使用率又被分为内核时间和用户时间。
  • 用户时间,执行用户态程序的时间被称为用户时间。
  • 内核时间,执行内核态代码的时间为内核时间,包含系统调用,内核线程和中断的时间。
  • 上下文切换,内核程序切换CPU让其在不同的地址空间上操作
  • 中断,由物理设备发送给内核的信号,通常是请求I/O服务

CPU高的常见原因

扫描行高

查看资源监控可以看出CPU使用率很高。

image.png

查看引擎监控操作行数

image.png

发现存在大量的全表扫描行,这个是导致CPU高的主要问题,对于一个查询来说,如果该查询返回10行数据,我们需要尽量保证SQL通过索引扫描10行数据返回,此时效率是最高的,而不是全表扫描100W行数据后过滤掉99%的数据,返回10行给客户端。评价一个查询是否扫描行很高就可以通过该查询的返回行和扫描行相比可以知道,如果扫描行远大于返回行说明该SQL可以通过创建合适索引可以极大程度的降低SQL的响应时间以及降低CPU资源的使用率。

通过das的性能洞察可以找出问题SQL

image.png

找到慢SQL后,可以参考RDS PG慢SQL问题,进行SQL的优化。

活跃会话高

查看资源监控

image.png

发现CPU使用率较高,此时系统态占用达到了23%,说明可能存在大量的系统调用或者中断导致系统态CPU使用率较高。

查看下引擎监控的操作行数

image.png

发现此时全表扫描行数并不高。

查看下引擎监控的连接情况

image.png

发现此时活跃会话数已达到279个,此实例规格为2C4G,因为CPU只有两个core,同时却有279个会话同时运行,此时CPU会频繁的进行上下文切换,导致CPU的系统态占用增加,降低了CPU实际去执行SQL的时间。此时说明数据库资源已远超目前能提供服务的负载。一般合理的活跃会话数量是当前实例规格CPU数量的2-3倍,例如实例规格为2C4G,性能最高的情况为活跃会话数不超过4-6个,此时CPU使用效率最高,绝大多数CPU资源都用于执行SQL,而不是进行上下文切换或者中断等。

查看DAS中的会话管理,查看当前活跃状态的SQL以及数量。

image.png

查看DAS中的性能洞察查看当前具体的SQL分布,以及SQL的等待事件

image.png

对于这类情况,需要考虑进行规格的升级,或者降低并发降低活跃会话的数量,保存活跃会话在一个合理的范围内。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接