MySQL · 专家投稿 · MySQL数据库SYS CPU高的可能性分析

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB PostgreSQL 版,企业版 4核16GB
推荐场景:
HTAP混合负载
简介: 问题背景 我们在管理繁忙的 MySQL 数据库时,可能都有碰到 SYS CPU 高的经历:系统突然 SYS CPU 高起来,甚至比 USER CPU 高很多,这时系统 QPS、TPS 急剧下降。 SYS CPU高是什么造成的呢?主要有2种可能: 1. context switch 不高,但

问题背景

我们在管理繁忙的 MySQL 数据库时,可能都有碰到 SYS CPU 高的经历:系统突然 SYS CPU 高起来,甚至比 USER CPU 高很多,这时系统 QPS、TPS 急剧下降。

SYS CPU高是什么造成的呢?主要有2种可能:
1. context switch 不高,但在内核态 spin,导致 SYS CPU 高
2. context switch 高,每秒超过 200K,有时超过1M,过多 context switch 导致 SYS CPU 高

下面我们对这两种情况逐一分析。

context switch 不高,但在内核态 spin

MySQL 在内核态 spin,说明需要系统资源,当这个资源紧张不足时,就会在内核态 spin。

有些资源,用户进程(或线程)通过执行系统调或因中断进入内核,一般来说申请这些资源的执行时间很短,当出现资源争用时,如果采用 sleep 再唤醒机制,代价较大,因此多采用在内核态spin的策略。

例如申请内存或发生缺页中断,没有 free 内存可用时,进程或线程就可能在内核态先执行内存回收再执行内存分配,但系统内存是共享资源,分配回收时需要锁保护,当多个进程(或线程)同时回收分配内存时。就会在内核态 spin。

当 free 内存不足时,可能出现这种情况。典型症状:

  1. MySQL running 高,但系统 qps、tps 下降
  2. 系统 free 内存不足;或系统 free 内存充足时,但启用了 numa 内存分配策略,有的节点 free 内存很少
  3. 系统 context switch 不高
  4. MySQL InnoDB 的 mutex、RWlock 查不到等待信息
  5. sar -B 显示有 pgscand 产生

分析

当系统内存不足时,MySQL 突然有大量访问,紧急需要大量内存,kswapd 在短时间内回收不了足够多的 free 内存,或 kswapd 还没有触发执行,这时 MySQL 用户线程就会在内核态执行内存回收操作,从而出现以上症状。

sar -B 输出中,pgscank 是表示内核线程 kswapd 回收内存,k意思是 kernel;pgscand是表示用户进程或线程直接回收内存,d意思是direct。

解决办法:保证系统有充足 free 内存可用,NUMA 环境要求每个节点都有足够free内存可用。

由于 Linux 系统会尽量使用 free 内存,一个运行很久的 Linux 系统,free内存通常很少,存在大量 filecache 内存,但 Linux 没有直接提供控制 filecache 占用多少的参数,那怎么能够保留足够可用的 free 内存,以应对突然内存需求呢?

对此,Linux 2.3.32+ 内核中增加一个新的参数vm.extra_free_kbytes,就是控制free内存的。

关于系统free内存,有2个重要参数:vm.min_free_kbytes 和 vm.extra_free_kbytes(2.6.32+)

vm.min_free_kbytes:系统保留给内核用的内存。

这个值决定 /proc/zoneinfo 中 zone 的min值。当系统 free 内存小于这个值时,kswapd 会回收内存,直到free内存达到/proc/zoneinfo中 high 值才停止回收;

当用户进程或线程分配内存或发生缺页中断时,free 内存少于 vm.min_free_kbytes,会在用户线程上下文中直接进行回收内存(pgscand)和分配内存。

vm.extra_free_kbytes:系统保留给应用的free内存。

这个值决定了/proc/zoneinfo中Normal zone的low值。当系统free内存小于vm.min_free_kbytes + vm.extra_free_kbytes 时,kswapd会开始回收内存,直到free内存达到 /proc/zoneinfo 中high值才停止回收。

这个额外的vm.extra_free_kbytes就是给应用突发内存需求时使用的,避免急需内存时发生pgscand或kswapd回收内存不及时。

vm.extra_free_kbytes 分配多大合适呢?一般能应对流量高峰时1-2秒内存需求就可以了。free内存减少后,kswapd进程会在后台回收内存的,一般512M-2G可以满足要求。

context switch 高

有很多种情况都会导致 context switch。MySQL 中的 mutex 和 RWlock 在获取不成功后,短暂spin,还不成功,就会发生 context switch,sleep,等待唤醒。

在 MySQL中,mutex 和 RWlock导致的 context switch,一般在show global status,show engine innodb mutex,show engine innodb status,performance_schema等中会体现出来,针对不同的mutex和RWlock等待,可以采取不同的优化措施。

除了MySQL的mutex和RWlock,还发现一种情况,是MySQL外的mutex竞争导致context switch高。

典型症状:

  1. MySQL running 高,但系统 qps、tps 低
  2. 系统context switch很高,每秒超过200K
  3. 在 MySQL 内存查不到mutex和RWlock竞争信息
  4. SYS CPU 高,USER CPU 低
  5. 并发执行的SQL中出现timestamp字段,MySQL的time_zone设置为system

分析

对于使用 timestamp 的场景,MySQL 在访问 timestamp 字段时会做时区转换,当 time_zone 设置为 system 时,MySQL 访问每一行的 timestamp 字段时,都会通过 libc 的时区函数,获取 Linux 设置的时区,在这个函数中会持有mutex,当大量并发SQL需要访问 timestamp 字段时,会出现 mutex 竞争。

MySQL 访问每一行都会做这个时区转换,转换完后释放mutex,所有等待这个 mutex 的线程全部唤醒,结果又会只有一个线程会成功持有 mutex,其余又会再次sleep,这样就会导致 context switch 非常高但 qps 很低,系统吞吐量急剧下降。

解决办法:设置time_zone=’+8:00’,这样就不会访问 Linux 系统时区,直接转换,避免了mutex问题。

另外,对于spin消耗,MySQL配置变量中的innodb_spin_wait_delay 和 innodb_sync_spin_loops 可以用于微调。

作者介绍
高亚芳 北京理工大学计算机系毕业,IT行业老兵,目前负责数据存储基础架构工作,开源爱好者。


相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
10天前
|
存储 关系型数据库 MySQL
探索MySQL:关系型数据库的基石
MySQL,作为全球最流行的开源关系型数据库管理系统(RDBMS)之一,广泛应用于各种Web应用、企业级应用和数据仓库中
|
7天前
|
关系型数据库 MySQL 网络安全
Mysql 数据库主从复制
在MySQL主从复制环境中,配置了两台虚拟机:主VM拥有IP1,从VM有IP2。主VM的`my.cnf`设置server-id为1,启用二进制日志;从VM设置server-id为2,开启GTID模式。通过`find`命令查找配置文件,编辑`my.cnf`,在主服务器上创建复制用户,记录二进制日志信息,然后锁定表并备份数据。备份文件通过SCP传输到从服务器,恢复数据并配置复制源,启动复制。检查复制状态确认运行正常。最后解锁表,完成主从同步,新用户在从库中自动更新。
943 6
Mysql 数据库主从复制
|
8天前
|
缓存 运维 关系型数据库
数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比
经过深入的技术剖析与性能对比,PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计,在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势,但MGR在MySQL生态体系内也占据重要地位,但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况,因此如果想用好MGR,必须配备专业的技术和运维团队的支持。 在面对大规模、高并发、高可用性需求时,PolarDB-X存储引擎以其独特的技术优势和优异的性能表现,相比于MGR在开箱即用的场景下,PolarDB-X基于DN的集中式(标准版)在功能和性能都做到了很好的平衡,成为了极具竞争力的数据库解决方案。
|
13天前
|
XML Java 关系型数据库
Action:Consider the following: If you want an embedde ,springBoot配置数据库,补全springBoot的xml和mysql配置信息就好了
Action:Consider the following: If you want an embedde ,springBoot配置数据库,补全springBoot的xml和mysql配置信息就好了
|
13天前
|
关系型数据库 MySQL 数据库
关系型数据库mysql数据增量恢复
【7月更文挑战第3天】
128 2
|
13天前
|
关系型数据库 MySQL Shell
关系型数据库mysql数据完全恢复
【7月更文挑战第3天】
83 2
|
13天前
|
存储 关系型数据库 MySQL
|
14天前
|
存储 关系型数据库 MySQL
|
7天前
|
关系型数据库 数据库 RDS
利用DTS将自建mysql5.7版本数据库迁移至对应rds报错
利用DTS将自建mysql5.7版本数据库迁移至对应rds报错
30 0
|
11天前
|
XML 关系型数据库 MySQL
支付系统----微信支付19---集成MyBatis-plus,数据库驱动对应的依赖版本设置问题,5没版本没有cj这个依赖,mysql驱动默认的是版本8,这里是一个父类,数据库都有,写个父类,继承就行
支付系统----微信支付19---集成MyBatis-plus,数据库驱动对应的依赖版本设置问题,5没版本没有cj这个依赖,mysql驱动默认的是版本8,这里是一个父类,数据库都有,写个父类,继承就行

相关产品

  • 云数据库 RDS MySQL 版