MySQL SYS CPU高的案例分析(一)

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
RDS Agent(兼容OpenClaw),2核4GB
简介: 原文:MySQL SYS CPU高的案例分析(一)【现象】 最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高。 下面的截图来源于“MySQL CPU报警”采集的文件     【问题分析】 可以分析出这服务器CPU升高的原因是由于表的高并发写入引起。
原文: MySQL SYS CPU高的案例分析(一)

【现象】

最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高。

下面的截图来源于“MySQL CPU报警”采集的文件

 

 

【问题分析】

可以分析出这服务器CPU升高的原因是由于表的高并发写入引起。优化方案通常是通知开发停止写入或降低写入频率。

究竟是什么原因导致高并发写入时CPU sys的占比这么高。

从采集的【Perf Stat】指标看到CPU有大量消耗是集中kernel的spin_lock上,推测sys的消耗占比是由spin lock引起的

同时从这个系统调用中也可以比较清晰的看出一个INSERT语句的执行过程(只是执行路径上的部分关键函数),简单整理如下:

 

insert当获取不到rw-lock时,保持spin lock,进入短暂等待。高并发的大量访问出现资源竞争,大量线程出现spin lock及context switch,导致CPU飙升。

为了防止自旋锁循环过快,耗费CPU,MySQL中引入了innodb_spin_wait_delay参数,具体可参考下面的官方手册

https://dev.mysql.com/doc/refman/5.6/en/innodb-performance-spin_lock_polling.html

 

【问题重现】

在测试环境中,启用1000个并发线程模拟高并发写入的场景

 

1、innodb_spin_wait_delay和innodb_sync_spin_loops保持默认值不变

 

CPU idle在18%左右,sys占比40%多,TPS在1.5W左右

 

 

2、将变量适当增大SET GLOBAL innodb_spin_wait_delay=18;

(注意:18是在Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 40核的CPU经过多次测试得出的相对合理的值,建议该值大小不要超过24)

可以观察到CPU idle在15%左右,sys占比降到20%多,TPS增加到1.75W左右,MySQL的插入性能约提升了16.7%

 

 

【结论】

对于MySQL高并发写入的场景,我们可以通过微调innodb_spin_wait_delay参数,减少kernel的spin_lock消耗,降低CPU的sys占比,从而提升MySQL的TPS处理能力。


 

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
9月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
558 158
|
8月前
|
存储 消息中间件 监控
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
蒋星熠Jaxonic,数据领域技术深耕者。擅长MySQL到ClickHouse链路改造,精通实时同步、数据校验与延迟治理,致力于构建高性能、高一致性的数据架构体系。
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
|
8月前
|
SQL 监控 关系型数据库
【紧急救援】MySQL CPU 100%!一套组合拳教你快速定位并解决!
凌晨三点MySQL CPU飙至100%,业务瘫痪!本文亲历30分钟应急排障全过程:从紧急止血、定位慢查询、分析锁争用,到优化SQL与索引,最终恢复服务。总结一套可复用的排查路径与预防方案,助你告别深夜救火。
|
9月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
607 156
|
9月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
713 161
|
8月前
|
NoSQL 算法 Redis
【Docker】(3)学习Docker中 镜像与容器数据卷、映射关系!手把手带你安装 MySql主从同步 和 Redis三主三从集群!并且进行主从切换与扩容操作,还有分析 哈希分区 等知识点!
Union文件系统(UnionFS)是一种**分层、轻量级并且高性能的文件系统**,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。
872 6
|
9月前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器,操作系统为windows server。服务器上部署mysql单实例,innodb引擎,独立表空间。未进行数据库备份,未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句,导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份,也未开启binlog日志,无法直接还原数据库。
|
10月前
|
存储 关系型数据库 MySQL
深入理解MySQL索引类型及其应用场景分析。
通过以上介绍可以看出各类MySQL指标各自拥有明显利弊与最佳实践情墁,在实际业务处理过程中选择正确型号极其重要以确保系统运作流畅而稳健。
283 12
|
10月前
|
缓存 关系型数据库 MySQL
降低MySQL高CPU使用率的优化策略。
通过上述方法不断地迭代改进,在实际操作中需要根据具体场景做出相对合理判断。每一步改进都需谨慎评估其变动可能导致其他方面问题,在做任何变动前建议先在测试环境验证其效果后再部署到生产环境中去。
389 6
|
11月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理,这两种日志机制相互配合,能够有效地提升MySQL数据库的可靠性和稳定性。
350 10

推荐镜像

更多