线上 Linux 环境 MySQL 磁盘 IO 高负载深度排查与性能优化实战

目录

一、线上告警

二、问题诊断

1. 系统层面排查

2. 数据库层面分析

三、参数调优

1. sync_binlog 参数优化

2. innodb_flush_log_at_trx_commit 参数调整

四、其他优化建议

1. 日志文件位置调整

2. 生产环境核心参数配置模板

3. 突发 IO 高负载应急响应方案

五、风险提示

六、总结


一、线上告警

        某一天,生产环境监控系统突然报警:MySQL 磁盘 IOPS 持续超过 15000,平均响应时间突破 500ms,慢查询数量大量增加。登录数据库服务器发现:

  • 磁盘利用率长期维持在 98% 以上
  • iostat -x 1显示%util持续 100%
  • MySQL 进程 CPU 使用率达 90%,但大部分时间处于iowait状态

二、问题诊断

1. 系统层面排查

# 查看系统整体IO情况
$ iostat -x 1 10
Linux 5.4.0-150-generic (mysql-prod-01)  03/22/2025  _x86_64_  (32 CPU)avg-cpu:  %user   %nice %system %iowait  %steal   %idle7.2    0.00    4.5    12.3     0.0    76.0Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.0      0.0     0.0  14828.0      0.0  245440.0     33.1      7.5     0.5     0.0     0.5    0.0  99.8
sdb               0.0   4567.0   230.0   2800.0   18400.0  224000.0    152.8     12.5     4.1     2.8     4.2    0.3  99.9# 监控MySQL进程IO情况
$ pidstat -d 1
Linux 5.4.0-150-generic (mysql-prod-01)  03/22/2025  _x86_64_  (32 CPU)15:30:01      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
15:30:02        0     12345      0.00  245760.00      0.00  mysqld# 分析IO请求分布
$ iotop -o
Total DISK READ :       0.00 B/s | Total DISK WRITE : 240.00 M/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE: 240.00 M/sTID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
12345 be/4  mysql       0.00 B/s 240.00 M/s  0.00 % 99.99 % mysqld --defaults-file=/etc/mysql/my.cnf

通过上述命令发现:

  • MySQL 进程(PID 12345)占用了 92% 的磁盘写 IO
  • 大部分 IO 集中在/var/lib/mysql/ib_logfile0/var/lib/mysql/mysql-bin.000001文件

2. 数据库层面分析

-- 查看InnoDB日志等待情况
mysql> SHOW ENGINE INNODB STATUS\G
*************************** 1. row ***************************Type: InnoDBName: 
Status: 
=====================================
2025-03-22 15:35:23 0x7f8a1c000700 INNODB MONITOR OUTPUT
=====================================
[...]
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
288334 OS file reads, 1234567 OS file writes, 876543 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 245.00 writes/s, 120.00 fsyncs/s
[...]-- 分析慢查询日志
$ pt-query-digest /var/log/mysql/slow.log > slow_query_report.txt

关键发现:

  • InnoDB 日志等待事件占比达 68%
  • 大量简单 INSERT 语句执行时间超过 200ms
  • binlog 写入等待成为性能瓶颈

三、参数调优

1. sync_binlog 参数优化

原配置

mysql> SHOW VARIABLES LIKE '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1     |
+---------------+-------+
1 row in set (0.00 sec)

    sync_binlog=1 意味着每次事务提交都会强制将 binlog 写入磁盘,这是导致高 IO 的主要原因。在高并发写入场景下,这种配置会严重影响性能。

优化措施

-- 临时调整(立即生效)
mysql> SET GLOBAL sync_binlog=1000;
Query OK, 0 rows affected (0.00 sec)-- 验证修改结果
mysql> SHOW VARIABLES LIKE '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1000  |
+---------------+-------+
1 row in set (0.00 sec)-- 持久化配置(修改my.cnf)
$ sudo vi /etc/mysql/my.cnf
[mysqld]
sync_binlog=1000-- 重启MySQL服务使配置永久生效
$ sudo systemctl restart mysql

调整后效果:

  • 磁盘 IOPS 从 15000 降至 8000
  • 写入事务平均响应时间从 520ms 降至 85ms

2. innodb_flush_log_at_trx_commit 参数调整

原配置

mysql> SHOW VARIABLES LIKE '%innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.00 sec)

    innodb_flush_log_at_trx_commit=1 表示每次事务提交都要将日志写入磁盘,这进一步加重了 IO 负担。

优化措施

-- 临时调整
mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)-- 验证修改结果
mysql> SHOW VARIABLES LIKE '%innodb_flush_log%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout    | 1     |
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
2 rows in set (0.00 sec)-- 持久化配置
$ sudo vi /etc/mysql/my.cnf
[mysqld]
innodb_flush_log_at_trx_commit=2-- 重启MySQL服务
$ sudo systemctl restart mysql

调整后效果:

  • 磁盘 IOPS 进一步降至 5500
  • 写入吞吐量提升 42%

四、其他优化建议

1. 日志文件位置调整

将 InnoDB 日志文件和 binlog 文件移动到专用 SSD 磁盘:

# 创建新的日志目录
$ sudo mkdir -p /data/mysql/logs /data/mysql/binlog
$ sudo chown -R mysql:mysql /data/mysql# 修改my.cnf
$ sudo vi /etc/mysql/my.cnf
[mysqld]
innodb_log_file_size = 512M
innodb_log_files_in_group = 2
innodb_log_group_home_dir = /data/mysql/logs
log-bin = /data/mysql/binlog/mysql-bin# 停止MySQL服务
$ sudo systemctl stop mysql# 复制现有日志文件
$ sudo cp -a /var/lib/mysql/ib_logfile* /data/mysql/logs/
$ sudo cp -a /var/lib/mysql/mysql-bin.* /data/mysql/binlog/# 修改文件权限
$ sudo chown -R mysql:mysql /data/mysql/logs
$ sudo chown -R mysql:mysql /data/mysql/binlog# 启动MySQL服务
$ sudo systemctl start mysql# 验证日志文件位置
$ sudo lsof -p $(pgrep mysqld) | grep -E 'ib_logfile|mysql-bin'
mysqld  12345  mysql  mem       REG       8,17  536870912  123456789 /data/mysql/logs/ib_logfile0
mysqld  12345  mysql  mem       REG       8,17  536870912  123456790 /data/mysql/logs/ib_logfile1
mysqld  12345  mysql    4u      REG       8,17      12345  123456791 /data/mysql/binlog/mysql-bin.000001

2. 生产环境核心参数配置模板

[mysqld]
# 事务日志同步策略
sync_binlog = 1000                # 每1000次提交刷盘(平衡性能与可靠性)
innodb_flush_log_at_trx_commit = 2 # 每秒刷盘一次(减少redo日志IO)# 内存与日志配置
innodb_buffer_pool_size = 8G      # 缓冲池大小(建议为物理内存50-70%)
innodb_log_file_size = 512M       # 单个日志文件大小(根据写入量调整)
innodb_log_files_in_group = 2     # 日志文件数量
innodb_io_capacity = 2000         # IO能力上限(SSD建议2000-5000)
innodb_write_io_threads = 16      # 异步写线程数
innodb_read_io_threads = 16       # 异步读线程数

3. 突发 IO 高负载应急响应方案

-- 突发IO高负载时临时降低同步频率
SET GLOBAL sync_binlog = 10000;
SET GLOBAL innodb_flush_log_at_trx_commit = 0;-- 查看当前线程状态
SHOW FULL PROCESSLIST;-- 终止长时间运行的查询
KILL 12345;

五、风险提示

  1. sync_binlog=1000意味着可能丢失最多 1000 个事务的 binlog 数据
  2. innodb_flush_log_at_trx_commit=2可能导致系统崩溃时丢失 1 秒内的事务
  3. 建议在实施前进行压测验证,确保业务可接受数据丢失风险

六、总结

        MySQL 磁盘 IO 高负载是生产环境常见问题,通过合理调整sync_binloginnodb_flush_log_at_trx_commit参数,结合架构优化措施,可以显著提升数据库性能。本次优化实践证明:

  • 合理的参数调优可带来 60% 以上的 IO 性能提升
  • 批量操作优化能有效减少日志写入次数

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.pswp.cn/diannao/84351.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

window 显示驱动开发-初始化和 DMA 缓冲区创建

若要指示 GPU 支持 GDI 硬件加速,显示微型端口驱动程序的 DriverEntry 函数实现必须使用指向驱动程序实现的 DxgkDdiRenderKm 函数的指针填充 DRIVER_INITIALIZATION_DATA 结构的 DxgkDdiRenderKm 成员。 DirectX 图形内核子系统调用 DxgkDdiRenderKm 函数&#xf…

Go语言实战:使用 excelize 实现多层复杂Excel表头导出教程

Go 实现支持多层复杂表头的 Excel 导出工具 目录 项目介绍依赖说明核心结构设计如何支持多层表头完整使用示例总结与扩展 项目介绍 在实际业务系统中,Excel 文件导出是一项常见功能,尤其是报表类需求中常见的复杂多级表头,常规表格组件往…

机器视觉6-halcon高级教程

机器视觉6-halcon高级教程 双目立体视觉原理视差外极线几何双目标定 双目立体视觉之Halcon标定一.标定结果二.Halcon标定过程1.获取左右相机图像中标定板的区域;2.提取左右相机图像中标定板的MARK点坐标和摄像机外部参数;3.执行双目标定;4.获取非标准外极线几何到标…

板凳-------Mysql cookbook学习 (六)

2025年Pytorch-gpu版本安装(各种情况适用自己的安装需求,亲测绝对有效,示例安装torch2.6.0,过程详细面向小白)_torch gpu版本-CSDN博客 https://blog.csdn.net/OpenSeek/article/details/145795127 2.2 查错 import s…

Spring boot和SSM项目对比

目录对比 springboot目录 project├─src│ ├─main│ │ ├─java│ │ │ ├─com.example.demo│ │ │ │ ├─config // 存放SpringBoot的配置类│ │ │ │ ├─controller // 存放控制器类│ │ │ │ ├─entity // 存…

《关于浔川社团退出DevPress社区及内容撤回的声明》

《关于浔川社团退出DevPress社区及内容撤回的声明》 尊敬的DevPress社区及读者: 经浔川社团内部决议,我社决定自**2025年5月26日**起正式退出DevPress社区,并撤回所有由我社成员在该平台发布的原创文章。相关事项声明如下: …

Python性能优化利器:__slots__的深度解析与避坑指南

核心场景:当需要创建数百万个属性固定的对象时,默认的__dict__字典存储会造成巨大内存浪费。此时__slots__能通过元组结构取代字典,显著提升内存效率(实测节省58%内存)! 底层原理:为何能节省内…

Go 语言中的 Struct Tag 的用法详解

在 Go 语言中,结构体字段标签(Struct Tag) 是一种用于给字段添加元信息(metadata)的机制,常用于序列化(如 JSON、XML)、ORM 映射、验证等场景。你在开发 Web 应用或处理数据交互时&a…

微软正式发布 SQL Server 2025 公开预览版,深度集成AI功能

微软在今年的 Build 2025 大会上正式发布了 SQL Server 2025 公开预览版,标志着这一经典数据库产品在 AI 集成、安全性、性能及开发者工具方面的全面升级。 AI 深度集成与创新 原生向量搜索:SQL Server 2025 首次将 AI 功能直接嵌入数据库引擎&#xff…

React从基础入门到高级实战:React 基础入门 - React 的工作原理:虚拟 DOM 与 Diff 算法

React 的工作原理:虚拟 DOM 与 Diff 算法 引言 React 是现代前端开发的明星框架,它的出现彻底改变了我们构建用户界面的方式。无论是动态的 Web 应用还是复杂的单页应用(SPA),React 都能以高效的渲染机制和简洁的组件…

解释一下NGINX的反向代理和正向代理的区别?

大家好,我是锋哥。今天分享关于【解释一下NGINX的反向代理和正向代理的区别?】面试题。希望对大家有帮助; 解释一下NGINX的反向代理和正向代理的区别? NGINX的反向代理和正向代理的区别主要体现在它们的功能和使用场景上。下面我会详细解释它们的定义…

Python学习——执行python时,键盘按下ctrl+c,退出程序

在 Python 中,当用户按下 CtrlC 时,程序默认会触发 KeyboardInterrupt 异常并终止。 1. 捕获 KeyboardInterrupt 异常(推荐) 使用 try-except 块直接捕获 KeyboardInterrupt 异常,适用于简单场景。 示例代码&#xff…

C++ 反向迭代器(Reverse Iterator)实现详解

目录 1. 反向迭代器概述 2. 代码实现分析 3. 关键点解析 3.1 模板参数设计 3.2 核心操作实现 4. 使用示例 1. 反向迭代器概述 反向迭代器是STL中一种重要的适配器,它允许我们以相反的顺序遍历容器。本文将详细讲解如何实现一个自定义的反向迭代器模板类。 2.…

动态DNS管理:【etcd+CoreDNS】 vs【BIND9】便捷性对比

对比 BIND9 集群和 etcdCoreDNS 集群在便捷性方面,通常情况下,对于需要动态、频繁变更 DNS 记录以及追求云原生和自动化集成的场景,etcdCoreDNS 方案更加便捷。 然而,“便捷性”也取决于具体的应用场景、团队的技术栈和运维习惯。…

基于大模型的短暂性脑缺血发作预测与干预全流程系统技术方案大纲

目录 一、系统概述二、系统架构(一)数据采集层(二)大模型核心层(三)应用服务层(四)数据存储与管理层三、全流程技术方案(一)术前阶段(二)术中阶段(三)术后阶段(四)并发症风险预测(五)手术方案制定(六)麻醉方案制定(七)术后护理(八)统计分析(九)技术验…

MSP430通用电机控制代码(Motor)设计与实现

一、代码结构概览 // Motor.h // Motor.h #ifndef __MOTOR_H_ #define __MOTOR_H_#include "A_include.h"void Motor_Init(void); // 初始化函数 void PWM_SET(int duty0, int duty1); // PWM设置函数#endif// Motor.c // Motor.c #include "Motor.h"…

25年软考架构师真题(回忆更新中)

论文题: 系统负载均衡设计方法事件驱动架构多模型数据库应用软件测试架构案例分析: 必选题:1.1填写质量属性的质量属性名 1.2解释器风格架构的组成图填空,以及解释为什么该模型适用解释器风格 选做题1redis2.1全量复制的流程图 <

优化用户体验:拦截浏览器前进后退、刷新、关闭、路由跳转等用户行为并弹窗提示

&#x1f9d1;‍&#x1f4bb; 写在开头 点赞 收藏 学会&#x1f923;&#x1f923;&#x1f923; 需求 首先列举一下需要拦截的行为&#xff0c;接下来我们逐个实现。 浏览器前进后退标签页刷新和关闭路由跳转 1、拦截浏览器前进后退 这里的实现是核心&#xff0c;涉及到大…

Docker:容器化技术

引言 传统部署环境逐渐不适应现在的企业开发&#xff0c;为了追求更加轻量&#xff0c;更加容易管理项目&#xff0c;引入了docker容器化技术去实现更加高效的部署环境。 一.docker风光下的内核功能和常用命令 1.docker容器和虚拟机的区别 我们在底层和应用层之间引入了一层do…

ping命令常用参数以及traceout命令

在网络故障排查和性能分析中&#xff0c;ping和 traceroute&#xff08;Windows中通常称为 tracert&#xff09;是两个极为重要的工具。它们帮助诊断网络连接问题&#xff0c;了解数据在网络中的传输路径。下面将详细介绍这两个命令的常用参数及其应用。 ping命令 ping命令用…