mysqld cpu飙升 使用率过高100% 原因与解决方法

今天,一位群友的服务器,他发现mysql数据库CPU占用率接近100%,偶尔甚至还超过100%。具体如下:

 

1、使用“top"命令查看,结果如下:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND   
1974 mysql     20   0 2470264 541028   11256 S   97.0  13.9   38:08.91 mysqld 

mysqld cpu飙升 使用率过高100% top命令查看

 

2、通过“宝塔面板”查看,结果如下:

负载状态:标红100% 运行堵塞

CPU使用率:标红100%

宝塔mysql负载状态:标红100% 运行堵塞 CPU使用率:标红100%

 

原因

由于这位群友也是搞技术的,他通过自己的不断排查,得出如下几个重要的结果:

1、网站流量是正常的(查了近30天的),没有突发异常。

2、服务器配置以及各硬件都是正常的,未做任何的改动。

3、未发现有人恶意攻击。

4、网站虽然有用memcached缓存,但也是正常的,没有所谓的“缓存雪崩”的情况。

 

最终:

通过不断排查,发现最主要的原因纯粹就是“数据库查询”所引起的,还是数据库的问题!

 

解决方法

通过上面,虽然说这位群友知道了大概的原因,也找对了方向,但是具体是什么原因造成的?又如何解决?他就不怎么清楚了,因此找到了我。以这位群友的情况为例子,我的整个解决步骤及思路如下:

 

既然这位群友排查出来了是mysql数据库的问题,通过"top"也知道了是“mysqld”这个进程所引起的,我就不再重新排查了,先按照他这个思路走,要相信别人的技术。

 

1、对于网站来说,mysql数据库的问题,一般都是SQL“查询”语句出问题多,我们可以通过“mysql慢日志“来做一个大概的了解。

可参考:MySQL慢查询日志(开启、位置、查看)使用教程

 

2、由于有“宝塔面板”,我就直接在面板里找到mysqld的“慢日志”,如下图:宝塔面板 mysqld 慢日志

 

3、通过这个mysqld“慢日志”我发现有很多类似如下的SQL语句:

# Time: 2022-11-18T12:50:33.181127Z
# User@Host: ymdclubdb[ymdclubdb] @ localhost []  Id:  7810
# Query_time: 13.304726  Lock_time: 0.000091 Rows_sent: 0  Rows_examined: 1315764
SET timestamp=1668775833;
SELECT * FROM wpymd_clean_up_optimizer_ip_locations WHERE ip='171.113.101.223';
# Time: 2022-11-18T12:50:33.788886Z
# User@Host: ymdclubdb[ymdclubdb] @ localhost []  Id:  7811
# Query_time: 13.589811  Lock_time: 0.000118 Rows_sent: 1  Rows_examined: 1315764
SET timestamp=1668775833;
SELECT * FROM wpymd_clean_up_optimizer_ip_locations WHERE ip='112.224.143.10';
# Time: 2022-11-18T12:50:34.238521Z
# User@Host: ymdclubdb[ymdclubdb] @ localhost []  Id:  7812
# Query_time: 13.292740  Lock_time: 0.000089 Rows_sent: 0  Rows_examined: 1315764
SET timestamp=1668775834;
SELECT * FROM wpymd_clean_up_optimizer_ip_locations WHERE ip='118.80.38.108';
# Time: 2022-11-18T12:50:35.861560Z
# User@Host: ymdclubdb[ymdclubdb] @ localhost []  Id:  7813
# Query_time: 14.392160  Lock_time: 0.000143 Rows_sent: 0  Rows_examined: 1315764
SET timestamp=1668775835;
SELECT * FROM wpymd_clean_up_optimizer_ip_locations WHERE ip='114.97.42.81';
# Time: 2022-11-18T12:50:35.912757Z
# User@Host: ymdclubdb[ymdclubdb] @ localhost []  Id:  7815
# Query_time: 14.089227  Lock_time: 0.000126 Rows_sent: 0  Rows_examined: 1315764
SET timestamp=1668775835;
SELECT * FROM wpymd_clean_up_optimizer_ip_locations WHERE ip='116.2.77.214';

通过上面这些SQL慢查询语句,分析可以得出以下几个结果:

  • 查询时间都在13秒以上
  • 查询行数都超过130万条数据了

 

4、通过上面这些SQL查询语句,我发现都在查询这个“wpymd_clean_up_optimizer_ip_locations”表。我仔细的问了一下这个群友,据他所说:网站是Wordpress开发的,用了一个叫“WP Clean Up Optimizer”的插件。

问:我还特意问了,这不是一个wordpress清理、优化数据库的插件吗?为什么每次进网站都需要去查询这个表呢?

答:他说除了清理、优化之外,还是一个安全插件,同一个IP输入密码四次错了就要锁IP。

 

5、为什么会出现查询需要13秒以上?为什么一张表的数据居然超过了百万(大概130万条数据左右)

我相信任何一个作为Wordpress的站长,都很清楚每天都会被大量机器人尝试登陆自己的站点已经不是什么鲜为人知的秘密。

为此带来的问题就是“wpymd_clean_up_optimizer_ip_locations”表会因为这些无效登陆而日益膨胀,数据会越来越多。

虽然我不清楚这个插件有什么理由需要在每次打开站点页面时都去查询这张表,但是任由这张表去膨胀而不加约束、甚至不提供功能开关、还不加索引查询,都是很蠢的行为,而这正是导致这一系列问题的元凶。

 

此时,最好的解决方法就是:删除“WP Clean Up Optimizer”插件。也只能删除此插件,这是因为:Clean Up Optimizer 插件,确实自带有记录近期尝试登陆的用户信息的功能,且这个功能无法关闭。

 

6、删除插件后,重启各种服务,等一段时间,CPU使用率恢复正常,负载也恢复正常。

 

总结:

mysql cpu 100%是很正常的现象,遇到这种情况的人也不在少数,也不必太担心。我这里只是教大家如何去具体的解决?仅仅只是提供一个解决问题的思路。或许你遇到的情况和我的原因有些细节问题不一样呢?

付杰
  • ¥ 79.0元
  • 市场价:99.0元
  • ¥ 1999.9元
  • 市场价:8999元
  • ¥ 68.0元
  • 市场价:168.0元
  • ¥ 199.0元
  • 市场价:199.0元

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: