场景:1:MySQL进程飙升900% 大家在使用MySQL过程,想必都有遇到过CPU突然过高,或者达到200%以上的情况。
数据库执行查询或数据修改操作时,系统需要消耗大量的CPU资源维护从存储系统、内存数据中的一致性。
并发量大并且大量SQL性能低的情况下,比如字段是没有建立索引,则会导致快速CPU飙升,如果还开启了慢日志记录,会导致性能更加恶化。生产上有MYSQL 飙升900% 的恶劣情况。
场景2:Java进程飙升900% 一般来说Java 进程不做大量 CPU 运算,正常情况下,CPU 应该在 100~200% 之间,
但是,一旦高并发场景,要么走到了死循环,要么就是在做大量的 GC, 容易出现这种 CPU 飙升的情况,CPU飙升900%,是完全有可能的。
其他场景:其他的类似进程飙升900%的场景 比如Redis、Nginx等等。
陈某提示:大家介绍场景的时候,就说自己主要涉及了两个场景,
Java进程飙升900%、MySQL进程飙升900%两种场景,其实,这两个场景就足够讲半天了, 其他的,使用规避技巧规避一下就行。
场景一:MySQL进程CPU飙升到900%,怎么处理?
定位过程:
使用top 命令观察,确定是mysqld导致还是其他原因。
如果是mysqld导致的,show processlist,查看session情况,确定是不是有消耗资源的sql在运行。
找出消耗高的 sql,看看执行计划是否准确, index 是否缺失,或者实在是数据量太大造成。
处理过程:
kill 掉这些线程(同时观察 cpu 使用率是否下降), 一般来说,肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降),等进行相应的调整(比如说加索引、改 sql、改内存参数)之后,再重新跑这些 SQL。
进行相应的调整(比如说加索引、改 sql、改内存参数)
index 是否缺失,如果是,则 建立索引。也有可能是每个 sql 消耗资源并不多,但是突然之间,有大量的 session 连进来导致 cpu 飙升,这种情况就需要跟应用一起来分析为何连接数会激增,再做出相应的调整,比如说限制连接数等;
优化的过程,往往不是一步完成的,而是一步一步,执行一项优化措辞,再观察,再优化。
场景1的真实案例:MySQL数据库优化的真实案例
陈某提示:以下案例,来自互联网。大家参考一下,准备一个自己的案例。
本问题亲身经历过。
之前开发同事编写的SQL语句,就导致过线上CPU过高,MySQL的CPU使用率达到900%+,通过优化最后降低到70%~80%。下面说说个人在这个过程中的排查思路。
首先,我们要对问题定位而不是盲目的开启什么 慢日志,在并发量大并且大量SQL性能低的情况下,开启慢日志无意是将MySQL推向崩溃的边缘。
当时遇到这个情况,分析了当前的数据量、索引情况、缓存使用情况。目测数据量不大,也就几百万条而已。接下来就去定位索引、缓存问题。
经过询问,发现很多查询都是走MySQL,没有用到缓存。
既然没有用到缓存,则是大量请求全部查询MySQL导致。通过下面的命令查看:
show processlist;
发现类似很多相同的SQL语句,一直处于query状态中。
select id form user where user_code = 'xxxxx';
初步分析可能是 user_code 字段没有索引导致。接着查询user表的索引情况:
show index form user;
发现这个字段是没有建立索引。增加索引之后,该条SQL查询能够正常执行。
3、没隔一会,又发生大量的请求超时问题。接着进行分析,发现是开启了 慢日志查询。大量的SQL查询语句超过慢日志设置的阀值,于是将慢日志关闭之后,速度瞬间提升。CPU的使用率基本保持在300%左右。但还不是理想状态。
4、紧接着将部分实时查询数据的SQL语句,都通过缓存(redis)读写实现。观察一段时间后,基本维持在了70%~80%。
总结:其实本次事故的解决很简单,就是添加索引与缓存结合使用。
不推荐在这种CPU使用过高的情况下进行慢日志的开启。因为大量的请求,如果真是慢日志问题会发生日志磁盘写入,性能贼低。
直接通过MySQL show processlist命令查看,基本能清晰的定位出部分查询问题严重的SQL语句,在针对该SQL语句进行分析。一般可能就是索引、锁、查询大量字段、大表等问题导致。
再则一定要使用缓存系统,降低对MySQL的查询频次。
对于内存调优,也是一种解决方案。
场景2展开:Java进程CPU飙升到900%,怎么处理?
定位过程:
CPU飙升问题定位的一般步骤是:
首先通过top指令查看当前占用CPU较高的进程PID;
查看当前进程消耗资源的线程PID:top -Hp PID