[转发大师姐 李坤]MySQL参数 time_zone 导致线上sys cpu高

2023-10-17 14:50

本文主要是介绍[转发大师姐 李坤]MySQL参数 time_zone 导致线上sys cpu高,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

先放链接:https://mp.weixin.qq.com/s/AtyaIP92L6KnZFB9bQA3ug

帮qunar公众号宣传一波!!!


事故现场



16:27分钟时刻,系统CPU突然标高,大部分都是system,同时processlist暴增,running最高到1500,应用反应超时。

系统其他资源正常,io、网络、内存,都在正常使用范围。网络和io掉了一些,分析不是他们的问题。


线上有大量的这个sql:


select

         count(*)

        from db.table where create_time>= '2017-07-01 00:00:00' and create_time < '2017-08-0100:00:00'AND type='A';


表结构很简单,索引使用正常,表只有1w多行,查询的结果集也只有几千行。

这种情况,开始怀疑是并发突增,看了qps并没有增高,业务也没有变更,这个sql的qps也只有40,平时执行0.0xs。故障期间qps并没有突增,因此连接数增高、并发的增高解释为响应变慢。

而且cpu大量的sys这不正常,排查如下:   

  • 排查了硬件故障,建立链接会消耗syscpu,但应该是瞬间,不应该cpu是持续的

  • 排查了应用对端,如果tcp协议数据发的很慢,网络堆在mysql发送也会导致sys,同时导致增大链接,排查了没问题。

  • 数据库没有报错

  • 没有其他明显慢sql

  • 查询了以往并发突增导致的故障,并没有syscpu

线上临时把这个业务下线,解决了故障。但没有找到根本原因。

 

环境复现:



之后和开发在离线库抱着试一试的心态复现环境,开启30个线程去查询,也用了sysbench去压测这个sql,复现了问题。(之所以没有选线上从库,看之前的监控,写节点性能低,pxc从库qps也受到了影响)

异常现象和线上几乎一致,sys高,running高,qps低。


然后重点开始分析cpu。异常时系统级别cpu上下文切换偏高,是正常的10倍:


这里抓到cpu大量用在kernel的spin自旋锁:


pstack:看到大量的线程在调用 Time_zone_system 方法


这些线索,大量时间花在cpu的spin,联想到了之前分析时看到的文章,http://webcache.googleusercontent.com/search?q=cache:p_AeVu4QhL8J:glume.blog.chinaunix.net/uid-20708886-id-5105437.html+&cd=1&hl=zh-CN&ct=clnk&gl=hk


对于使用 timestamp 的场景,MySQL 在访问 timestamp 字段时会做时区转换,当 time_zone 设置为 system 时,MySQL 访问每一行的 timestamp 字段时,都会通过 libc 的时区函数,获取 Linux 设置的时区,在这个函数中会持有mutex,当大量并发SQL需要访问 timestamp 字段时,会出现 mutex 竞争。MySQL 访问每一行都会做这个时区转换,转换完后释放mutex,所有等待这个 mutex 的线程全部唤醒,结果又会只有一个线程会成功持有 mutex,其余又会再次sleep,这样就会导致 context switch 非常高但 qps 很低,系统吞吐量急剧下降。


总结下文章,就是当time_zone=system的时候,查询timestamp字段,会调用系统的时区做时区转换,有全局锁__libc_lock_lock的保护,导致线程并发环境下,系统性能受限。

如果将time_zone='+8:00'则不会调用系统时区,则不会触发系统时区转换,使用mysql自身转换,大大提高了性能。


结论



将time_zone改为'+8:00'后,再次压测性能正常,验证了上面的分析。


MySQL 中的 mutex 在获取不成功后,短暂spin,如果还不成功,会发生context switch。这个故障就是在读取系统时区转换函数时,持有了mutex,mutex独占的,大量的访问会出现资源竞争,读完才会释放mutex,导致其他并发线程的spin以及cs,从而导致高running和相应慢,cpu飙升,又加剧了其他sql的响应。


后话



qunar线上time_zone都设置的system,并且这个sql也上线有一段时间了,怎么突然出现问题。

根据开发所说,之前该表5k行,7月初开始量逐步加大。我也测试了如果读取数量降低到1k的话,是没有这个问题的,还有降低些qps(降低到10)都不会触发这个问题,因此想应该是qps和读取行数协调作用,每一行都会触发转换,触发了资源的争抢导致这个问题。



这篇关于[转发大师姐 李坤]MySQL参数 time_zone 导致线上sys cpu高的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/226132

相关文章

MySQL 中的 CAST 函数详解及常见用法

《MySQL中的CAST函数详解及常见用法》CAST函数是MySQL中用于数据类型转换的重要函数,它允许你将一个值从一种数据类型转换为另一种数据类型,本文给大家介绍MySQL中的CAST... 目录mysql 中的 CAST 函数详解一、基本语法二、支持的数据类型三、常见用法示例1. 字符串转数字2. 数字

Mysql实现范围分区表(新增、删除、重组、查看)

《Mysql实现范围分区表(新增、删除、重组、查看)》MySQL分区表的四种类型(范围、哈希、列表、键值),主要介绍了范围分区的创建、查询、添加、删除及重组织操作,具有一定的参考价值,感兴趣的可以了解... 目录一、mysql分区表分类二、范围分区(Range Partitioning1、新建分区表:2、分

MySQL 定时新增分区的实现示例

《MySQL定时新增分区的实现示例》本文主要介绍了通过存储过程和定时任务实现MySQL分区的自动创建,解决大数据量下手动维护的繁琐问题,具有一定的参考价值,感兴趣的可以了解一下... mysql创建好分区之后,有时候会需要自动创建分区。比如,一些表数据量非常大,有些数据是热点数据,按照日期分区MululbU

SQL Server配置管理器无法打开的四种解决方法

《SQLServer配置管理器无法打开的四种解决方法》本文总结了SQLServer配置管理器无法打开的四种解决方法,文中通过图文示例介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的... 目录方法一:桌面图标进入方法二:运行窗口进入检查版本号对照表php方法三:查找文件路径方法四:检查 S

MySQL 删除数据详解(最新整理)

《MySQL删除数据详解(最新整理)》:本文主要介绍MySQL删除数据的相关知识,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录一、前言二、mysql 中的三种删除方式1.DELETE语句✅ 基本语法: 示例:2.TRUNCATE语句✅ 基本语

MySQL中查找重复值的实现

《MySQL中查找重复值的实现》查找重复值是一项常见需求,比如在数据清理、数据分析、数据质量检查等场景下,我们常常需要找出表中某列或多列的重复值,具有一定的参考价值,感兴趣的可以了解一下... 目录技术背景实现步骤方法一:使用GROUP BY和HAVING子句方法二:仅返回重复值方法三:返回完整记录方法四:

从入门到精通MySQL联合查询

《从入门到精通MySQL联合查询》:本文主要介绍从入门到精通MySQL联合查询,本文通过实例代码给大家介绍的非常详细,需要的朋友可以参考下... 目录摘要1. 多表联合查询时mysql内部原理2. 内连接3. 外连接4. 自连接5. 子查询6. 合并查询7. 插入查询结果摘要前面我们学习了数据库设计时要满

MySQL查询JSON数组字段包含特定字符串的方法

《MySQL查询JSON数组字段包含特定字符串的方法》在MySQL数据库中,当某个字段存储的是JSON数组,需要查询数组中包含特定字符串的记录时传统的LIKE语句无法直接使用,下面小编就为大家介绍两种... 目录问题背景解决方案对比1. 精确匹配方案(推荐)2. 模糊匹配方案参数化查询示例使用场景建议性能优

Java内存分配与JVM参数详解(推荐)

《Java内存分配与JVM参数详解(推荐)》本文详解JVM内存结构与参数调整,涵盖堆分代、元空间、GC选择及优化策略,帮助开发者提升性能、避免内存泄漏,本文给大家介绍Java内存分配与JVM参数详解,... 目录引言JVM内存结构JVM参数概述堆内存分配年轻代与老年代调整堆内存大小调整年轻代与老年代比例元空

mysql表操作与查询功能详解

《mysql表操作与查询功能详解》本文系统讲解MySQL表操作与查询,涵盖创建、修改、复制表语法,基本查询结构及WHERE、GROUPBY等子句,本文结合实例代码给大家介绍的非常详细,感兴趣的朋友跟随... 目录01.表的操作1.1表操作概览1.2创建表1.3修改表1.4复制表02.基本查询操作2.1 SE