关于RDS实例CPU超过100%的分析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

经常听见用户说自己的rds实例cpu超过100%,通常这种情况都是由于sql性能问题导致的,下面我用一则案例来分析:

用户实例zuowenwang反映cpu超过100%,实例偶尔出现卡住的现象;

1.原理:cpu消耗过大通常情况下都是有慢sql造成的,这里的慢sql包括全表扫描,扫描数据量过大,内存排序,磁盘排序,锁争用等待等;

2.表现现象sql执行状态为:sending data,Copying to tmp table,Copying to tmp table on disk,Sorting result,locked;

3.解决方法:用户可以登录到rds,通过show processlist查看当前正在执行的sql,当执行完show processlist后出现大量的语句,通常其状态出现sending data,Copying to tmp table,Copying to tmp table on disk,Sorting result, Using filesort 都是sql有性能问题;

A.sending data表示:sql正在从表中查询数据,如果查询条件没有适当的索引,则会导致sql执行时间过长;

B.Copying to tmp table on disk:出现这种状态,通常情况下是由于临时结果集太大,超过了数据库规定的临时内存大小,需要拷贝临时结果集到磁盘上,这个时候需要用户对sql进行优化;

C.Sorting result, Using filesort:出现这种状态,表示sql正在执行排序操作,排序操作都会引起较多的cpu消耗,通常的优化方法会添加适当的索引来消除排序,或者缩小排序的结果集;

通过show processlist发现如下sql:

Sql A.

| 2815961 | sanwenba  | 10.241.142.197:55190 | sanwenba | Query   | 0 | Sorting RESULT       | 
SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid 
ORDER BY za.viewnum DESC LIMIT 10;

性能sql:

SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid
 ORDER BY za.viewnum DESC LIMIT 10;

用explain 查看执行计划:

sanwenba@3018 10:00:54>explain SELECT z.aid,z.subject FROM www_zuowen z 
RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10;
 
+----+-------------+-------+--------+---------------+---------+---------+-----------------+------
 
| id | select_type | TABLE | TYPE   | possible_keys | KEY     | key_len | REF     | ROWS   | Extra |
 
+----+-------------+-------+--------+---------------+---------+---------+-----------------+------
 
|  1 | SIMPLE      | za    | INDEX  | NULL          | viewnum | 6       | NULL            | 537029 | USING INDEXUSING filesort |
 
|  1 | SIMPLE      | z     | eq_ref | PRIMARY       | PRIMARY | 3       | sanwenba.za.aid |      1 |  |

添加适当索引消除排序:

sanwenba@3018 10:02:33 ALTER TABLE www_zuowenaddviews ADD INDEX ind_www_zuowenaddviews_viewnum(viewnum);
sanwenba@3018 10:03:27explain SELECT z.aid,z.subject FROM www_zuowen z RIGHT JOIN www_zuowenaddviews za ON za.aid=z.aid ORDER BY za.viewnum DESC LIMIT 10;
+----+-------------+-------+--------+---------------+--------------------------------+---------+-
 
| id | select_type | TABLE | TYPE   | possible_keys | KEY  | key_len | REF      | ROWS | Extra       |
 
+----+-------------+-------+--------+---------------+--------------------------------+---------+-
 
|  1 | SIMPLE      | za    | INDEX  | NULL  | ind_www_zuowenaddviews_viewnum | 3       | NULL       |   10 | USING INDEX |
 
|  1 | SIMPLE    | z     | eq_ref | PRIMARY PRIMARY | 3  | sanwenba.za.aid |    1 |             |
 
+----+-------------+-------+--------+---------------+--------------------------------+---------+-

Sql B:

| 2825321 | netzuowen | 10.200.120.41:44172  | netzuowen | Query |     2 | Copying TO tmp TABLE ON disk 
SELECT * FROM `www_article` WHERE 1=1 ORDER BY rand() LIMIT 0,30

这种sql order by rand()同样也会出现排序;

netzuowen@3018 10:23:55
EXPLAIN  SELECT * FROM `www_zuowensearch` WHERE checked = 1 ORDER BY rand() LIMIT 0,10 ;
+----+-------------+------------------+------+---------------+--------+---------+-------+------+
 
| id | select_type | TABLE            | TYPE | possible_keys | KEY    | key_len | REF   | ROWS | Extra|
 
+----+-------------+------------------+------+---------------+--------+---------+-------+------+
 
|  1 | SIMPLE      | www_zuowensearch | REF  | newest        | newest | 1       | const | 1443 | USING TEMPORARYUSING filesort |
 
+----+-------------+------------------+------+---------------+--------+---------+-------+------+

这种随机抽取一批记录的做法性能是很差的,表中的数据量越大,性能就越差:

解决方法如下:

http://www.piaoyi.org/php/MySQL-Order-By-Rand.html

第一种方案,即原始的 Order By Rand() 方法:

$sql=”SELECT * FROM content ORDER BY rand() LIMIT 12″;

$result=mysql_query($sql,$conn);

$n=1;

$rnds=”;

while($row=mysql_fetch_array($result)){

$rnds=$rnds.$n.”. <a href=’show”.$row[‘id’].”-“.strtolower(trim($row[‘title’])).”‘>”.$row[‘title’].”</a><br />\n”;

$n++;

}

3万条数据查12条随机记录,需要0.125秒,随着数据量的增大,效率越来越低。

第二种方案,改进后的 JOIN 方法:

for($n=1;$n<=12;$n++){

$sql=”SELECT * FROM `content` AS t1

JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM `content`)) AS id) AS t2

WHERE t1.id >= t2.id ORDER BY t1.id ASC LIMIT 1″;

$result=mysql_query($sql,$conn);

$yi=mysql_fetch_array($result);

$rnds = $rnds.$n.”. <a href=’show”.$yi[‘id’].”-“.strtolower(trim($yi[‘title’])).”‘>”.$yi[‘title’].”</a><br />\n”;

}

3万条数据查12条随机记录,需要0.004秒,效率大幅提升,比第一种方案提升了约30倍。缺点:多次select查询,IO开销大。

第三种方案,SQL语句先随机好ID序列,用 IN 查询(飘易推荐这个用法,IO开销小,速度最快):

$sql=”SELECT MAX(id),MIN(id) FROM content”;

$result=mysql_query($sql,$conn);

$yi=mysql_fetch_array($result);

$idmax=$yi[0];

$idmin=$yi[1];

$idlist=”;

for($i=1;$i<=20;$i++){

if($i==1){ $idlist=mt_rand($idmin,$idmax); }

else{ $idlist=$idlist.’,’.mt_rand($idmin,$idmax); }

}

$idlist2=”id,”.$idlist;

$sql=”select * from content where id in ($idlist) order by field($idlist2) LIMIT 0,12″;

$result=mysql_query($sql,$conn);

$n=1;

$rnds=”;

while($row=mysql_fetch_array($result)){

$rnds=$rnds.$n.”. <a href=’show”.$row[‘id’].”-“.strtolower(trim($row[‘title’])).”‘>”.$row[‘title’].”</a><br />\n”;

$n++;

}

3万条数据查12条随机记录,需要0.001秒,效率比第二种方法又提升了4倍左右,比第一种方法提升120倍。注,这里使用了 order by field($idlist2) 是为了不排序,否则 IN 是自动会排序的。缺点:有可能遇到ID被删除的情况,所以需要多选几个ID。

C.出现sending data的情况:

| 2833185 | sanwenba        | 10.241.91.81:45964   | sanwenba | Query    |     1 | Sending DATA   |
 SELECT * FROM `www_article` WHERE CONCAT(subject,description) LIKE '%??%' ORDER BY aid DESC LIMIT 75,15

性能sql:

SELECT * FROM `www_article` WHERE CONCAT(subject,description) like ‘%??%’ ORDER BY aid desc LIMIT 75,15

这种sql是典型的sql分页写法不规范的情况,需要将sql进行改写:

SELECT * FROM www_article t1,(SELECT aid FROM www_article WHERE CONCAT(subject,description) LIKE '%??%' ORDER BY aid DESC LIMIT 75,15) t2 WHERE t1.aid=t2.aid;

注意这里的索引需要改用覆盖索引:aid+ subject+description

优化后的结果:

总结:

Sql优化是性能优化的最后一步,虽然位于塔顶,他最直影响用户的使用,但也是最容易优化的步骤,往往效果最直接。

RDS-mysql由于有资源的隔离,不同的实例规格拥有的iops能力不同,比如新1型提供的iops为150个,也就是每秒能够提供150次的随机磁盘io操作,所以如果用户的数据量很大,内存很小,由于iops的限制,一条慢sql就很有可能消耗掉所有的io资源,而影响其他的sql查询,对于数据库来说就是所有的sql需要执行很长的时间才能返回结果,对于应用来说就会造成整体响应的变慢;所以优化永不止境,既可以帮助你的系统稳定,同时又可以节约你的成本,何乐不为。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
6天前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
39 3
|
12天前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
6天前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
46 6
|
6天前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
47 1
|
13天前
|
存储 弹性计算 关系型数据库
如何通过控制台创建RDS MySQL实例
本文介绍了通过控制台创建RDS MySQL实例的详细步骤,包括准备工作、选择计费方式、地域、实例规格、存储空间等关键配置,并指导用户完成下单与实例查看。
|
28天前
|
存储 关系型数据库 MySQL
深入理解MySQL索引类型及其应用场景分析。
通过以上介绍可以看出各类MySQL指标各自拥有明显利弊与最佳实践情墁,在实际业务处理过程中选择正确型号极其重要以确保系统运作流畅而稳健。
101 12
|
1月前
|
存储 弹性计算 网络协议
阿里云服务器ECS实例规格族详细介绍:计算型c9i、经济型e和通用算力u1实例CPU参数说明
阿里云ECS实例规格族包括计算型c9i、经济型e和通用算力型u1等,各自针对不同场景优化。不同规格族在CPU型号、主频、网络性能、云盘IOPS等方面存在差异,即使CPU内存相同,性能和价格也不同。
114 0
|
2月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理,这两种日志机制相互配合,能够有效地提升MySQL数据库的可靠性和稳定性。
107 10
|
2月前
|
SQL 关系型数据库 MySQL
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。(图解+秒懂+史上最全)
|
4月前
|
前端开发 关系型数据库 RDS
购买RDS实例报错SLR 授权:未授权,应该怎么处理?
在阿里云购买RDS实例时,可能会遇到“SLR未授权”的报错。解决方法如下:1. 使用主账号登录控制台以确保权限充足;2. 在RDS购买页面选择正确的地域、引擎和产品系列,触发授权弹窗;3. 确认授权即可解决问题,若出现前端Bug导致报错,刷新页面即可。建议优先使用主账号避免RAM子账号权限配置复杂的问题。
205 29

推荐镜像

更多