MySQL大事务导致的Insert慢的案例分析

栏目: 数据库 · 发布时间: 6年前

【问题】

有台 MySQL 服务器不定时的会出现并发线程的告警,从记录信息来看,有大量insert的慢查询,执行几十秒,等待flushing log,状态query end

MySQL大事务导致的Insert慢的案例分析

【初步分析】

从等待资源来看,大部分时间消耗在了innodb_log_file阶段,怀疑可能是磁盘问题导致,经过排查没有发现服务器本身存在硬件问题

MySQL大事务导致的Insert慢的案例分析

后面开启线程上升时pstack的自动采集,定位MySQL线程等待的位置。

【分析过程】

部署了pstack的自动抓取后,出现过6次thread concurrency >=50的告警(每次告警时会有大量的慢查询产生),有3次抓到了现场。

并发线程升高时,有50多个线程卡在Stage_manager::enroll_for函数,处于group commit阶段

MySQL大事务导致的Insert慢的案例分析

MySQL大事务导致的Insert慢的案例分析

线程0x519c5940对应的 SQL 语句如下,已经执行18秒

MySQL大事务导致的Insert慢的案例分析

Stage_manager::enroll_for函数的作用实现了多个线程在flush_stage阶段的排队。简单来说,对于一个分组的事务,是被leader线程去提交的,其他线程处于排队等待状态,等待leader线程将该线程的事务提交完成。

如果第一个线程执行慢,后面的线程都处于等待状态,整组事务无法提交。

MySQL大事务导致的Insert慢的案例分析

流程也可以理解如下,

Session A COMMIT-->拿到锁-->进行binlog写-->commit完成

Session B COMMIT-->等待锁--------------------------->拿到锁-->进行binlog写-->commit完成

第一个线程为什么执行很慢,分析了发生告警时间段的日志文件,发现日志中存在2个15M和20M的大事务

MySQL大事务导致的Insert慢的案例分析

查看日志明细,存在delete from的大事务删除语句,约包含23W条记录,ROW模式下删除23W条记录,会产生大约20M的日志文件,刷盘时间较长,阻塞了同一个分组下其他事务的提交。

MySQL大事务导致的Insert慢的案例分析

事务的开始时间与告警时间吻合

积压的分组下事务集中刷盘,反应到磁盘指标上可以看到在问题时间段的disk_write_kbytes指标出现明显的上升

MySQL大事务导致的Insert慢的案例分析

【优化方案】

1、 建议开发避免使用delete from 整表的大事务删除语句

【其他变通方案】

2、 Binlog 记录的ROW模式下会产生大量的日志,改为MIXED模式,理论上也可以解决问题

3、 更换性能好的磁盘

Linux公社的RSS地址https://www.linuxidc.com/rssFeed.aspx

本文永久更新链接地址: https://www.linuxidc.com/Linux/2018-10/154980.htm


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

无线:网络文化中激进的经验主义

无线:网络文化中激进的经验主义

[英] 阿德里安·麦肯齐 / 张帆 / 上海译文出版社 / 2018-9

本书研究了无线是如何成为当代人类经验的主角的。从路由器、智能电话、电子书、城市到在线工作、服务协议、玩具以及国家等各个方面,人们已经感觉到了无线技术所引发的变革。本书作者援引一个世纪之前的哲学技术来分析当代最前沿的后网络时代的人类状况。基于威廉•詹姆斯的实用主义哲学相关的彻底经验主义,作者提出了把失序的无线网络世界与人们的感知匹配起来的新方式。一起来看看 《无线:网络文化中激进的经验主义》 这本书的介绍吧!

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具