一、关于DB的写

1、数据库是一个写频繁的系统
2、后台写、写缓存
3、commit需要写入
4、写缓存失效或者写满-->写压力陡增-->写占读的带宽
  1、BBU失效
  2、写入突然增加、cache满
5、日志写入、脏缓冲区写入

 
二、写压力性能监控
  全面剖析写压力:多维度的对写性能进行监控。
1、OS层面的监控:iostat -x
[root@localhost mydata]# iostat -x
Linux 2.6.-.el6.x86_64 (localhost.chinaitsoft.com) // _x86_64_ ( CPU) avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.03 0.00 0.00 99.97 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
scd0 0.00 0.00 0.00 0.00 0.01 0.00 7.72 0.00 1.25 1.25 0.00 1.25 0.00
sdc 0.02 0.00 0.01 0.00 0.07 0.00 7.93 0.00 0.89 0.89 0.00 0.72 0.00
sda 0.18 0.13 0.13 0.05 5.38 1.43 37.95 0.00 6.63 3.99 13.77 2.23 0.04
sdb 0.03 0.00 0.01 0.00 0.12 0.00 8.72 0.00 1.14 0.80 35.89 0.71 0.00
  1、写入的吞吐量:wsec/s  sec=512字节=0.5K、写入的响应时间:await
  2、我们需要确认我们的系统是写入还是读取的系统,如果是写入为主的系统,写压力自然就大,相关状态值也就大些。
  3、监控系统的io状况,主要查看%util、r/s、w/s,一般繁忙度在70%,每秒写也在理想值了;但如果系统目前繁忙度低,每秒写很低,可以增加写入。
2、DB层面监控,有没有写异常:监控各种pending(挂起)
mysql> show global status like '%pend%';
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| Innodb_data_pending_fsyncs | 0 | #被挂起的fsync
| Innodb_data_pending_reads | 0 | #被挂起的物理读
| Innodb_data_pending_writes | 0 | #被挂起的写
| Innodb_os_log_pending_fsyncs | 0 | #被挂起的日志fsync
| Innodb_os_log_pending_writes | 0 | #被挂起的日志写
+------------------------------+-------+
5 rows in set (0.01 sec)
  写挂起次数值大于0,甭管是什么写挂起,出现挂起的话就说明出现写压力,所以值最好的是保持为0。监控“挂起”状态值,出现大于0且持续增加,报警处理。
3、写入速度监控:日志写、脏页写
  1、日志写入速度监控
mysql> show global status like '%log%written';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Innodb_os_log_written | 5120 |
+-----------------------+-------+
1 row in set (0.01 sec)
  2、脏页写入速度监控
mysql> show global status like '%a%written';
+----------------------------+---------+
| Variable_name | Value |
+----------------------------+---------+
| Innodb_data_written | 1073152 | #目前为止写的总的数据量,单位字节
| Innodb_dblwr_pages_written | 7 |
| Innodb_pages_written | 58 | #写数据页的数量
+----------------------------+---------+
3 rows in set (0.01 sec)
  3、关注比值:Innodb_dblwr_pages_written / Innodb_dblwr_writes,表示一次写了多少页
mysql> show global status like '%dblwr%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Innodb_dblwr_pages_written | 7 | #已经写入到doublewrite buffer的页的数量
| Innodb_dblwr_writes | 3 | #doublewrite写的次数
+----------------------------+-------+
2 rows in set (0.00 sec)
    1、如果该比值是64:1,说明doublewrite每次都是满写,写的压力很大。
    2、如果系统的double_write比较高的话,iostat看到的wrqm/s(每秒合并写的值)就高,因为double_write高意味着每次写基本上都是写2M,这时候就发生更多的合并,但wrqm/s高并不害怕,因为发生合并是好事,看wrqm/s和繁忙度能不能接受。 
4、脏页的量监控
mysql> show global status like '%dirty%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_dirty | 0 | #当前buffer pool中脏页的数量
| Innodb_buffer_pool_bytes_dirty | 0 | #当前buffer pool中脏页的总字节数
+--------------------------------+-------+
2 rows in set (0.01 sec) mysql> show global status like 'i%total%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| Innodb_buffer_pool_pages_total | 8192 | #buffer pool中数据页总量
+--------------------------------+-------+
1 row in set (0.01 sec)
  关注比值:Innodb_buffer_pool_pages_dirty / Innodb_buffer_pool_pages_total,脏页占比
  通过比值看脏页是否多,比如脏页10%的话,可以判断系统可能不是写为主的系统。
5、写性能瓶颈
mysql> show global status like '%t_free';
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| Innodb_buffer_pool_wait_free | 0 |
+------------------------------+-------+
1 row in set (0.01 sec) mysql> show global status like '%g_waits';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_log_waits | 0 |
+------------------+-------+
1 row in set (0.00 sec)
  1、Innodb_buffer_pool_wait_free,如果该值大于0,说明buffer pool中已经没有可用页,等待后台往回刷脏页,腾出可用数据页,这样就很影响业务了,hang住。
  2、Innodb_log_waits,如果该值大于0,说明写压力很大,出现了日志等待。
6、系统真实负载:rows增删改查 、事务提交、事务回滚
mysql> show global status like 'i%rows%';
+----------------------+-------+
| Variable_name | Value |
+----------------------+-------+
| Innodb_rows_deleted | 0 |
| Innodb_rows_inserted | 145 |
| Innodb_rows_read | 233 |
| Innodb_rows_updated | 5 |
+----------------------+-------+
4 rows in set (0.01 sec) mysql> show global status like '%commit%';
+----------------+-------+
| Variable_name | Value |
+----------------+-------+
| Com_commit | 0 |
| Com_xa_commit | 0 |
| Handler_commit | 16 |
+----------------+-------+
3 rows in set (0.01 sec) mysql> show global status like '%rollback%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Com_rollback | 0 |
| Com_rollback_to_savepoint | 0 |
| Com_xa_rollback | 0 |
| Handler_rollback | 0 |
| Handler_savepoint_rollback | 0 |
+----------------------------+-------+
5 rows in set (0.01 sec)
  通过监控系统真实负载,如果业务正常,负载上升,写压力是那自然是无可厚非的。此时,就要根据业务具体情况,进行相应的调优。 
 
三、写压力调优参数
  降低写压力、加大写入的力度。
  通过调整参数降低写压力时,一定要实时关注iostat系统的各项指标。
1、脏页刷新的频率
mysql> show variables like 'i%depth%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024 |
+-----------------------+-------+
1 row in set (0.01 sec)
  默认1024,遍历lru list刷新脏页,值越大,说明刷脏页频率越高。
2、磁盘刷新脏页的量:磁盘io能力
mysql> show variables like '%io_c%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| innodb_io_capacity | 200 |
| innodb_io_capacity_max | 2000 |
+------------------------+-------+
2 rows in set (0.00 sec)
  根据磁盘io能力进行调整,值越大,每次刷脏页的量越大。
3、redolog调优
mysql> show variables like 'innodb_log%';
+-----------------------------+----------+
| Variable_name | Value |
+-----------------------------+----------+
| innodb_log_buffer_size | 16777216 |
| innodb_log_checksums | ON | #解决数据在io环节的出错问题,checksum值检查
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 50331648 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_log_write_ahead_size | 8192 |
+-----------------------------+----------+
7 rows in set (0.01 sec)
  logfile大小和组数可能会导致写抖动:日志切换频率需要监控(文件系统层面技巧)。
4、redolog的刷新机制
mysql> show variables like '%flush%commit';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)
  默认MySQL的刷盘策略是1,最安全的,但是安全的同时,自然也就会带来一定的性能压力。在写压力巨大的情况下,根据具体的业务场景,牺牲安全性的将其调为0或2。
关于redolog的刷盘策略:
  也就是用户在commit,事务提交时,处理redolog的方式(0、1、2):
  0:当提交事务时,并不将事务的redo log写入logfile中,而是等待master thread每秒的刷新redo log。(数据库崩溃丢失数据,丢一秒钟的事务)
  1:执行commit时将redo log同步写到磁盘logfile中,即伴有fsync的调用(默认是1,保证不丢失事务)
  2:在每个提交,日志缓冲被写到文件系统缓存,但不是写到磁盘的刷新(数据库宕机而操作系统及服务器并没有宕机,当恢复时能保证数据不丢失;但是文件系统(OS)崩溃会丢失数据)
5、定义每次日志刷新的时间
mysql> show variables like 'innodb_flush_log_at_timeout';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
+-----------------------------+-------+
1 row in set (0.01 sec)
  默认是1,也就是每秒log刷盘,配合innodb_flush_log_at_trx_commit来设置,为了充分保证数据的一致性,一般innodb_flush_log_at_trx_commit=1,这样的话,innodb_flush_log_at_timeout的设置也就没有意义了。因此,该参数的设置只针对innodb_flush_log_at_trx_commit为0/2起作用。
6、内存脏页占比控制
mysql> show variables like '%dirty%pct%';
+--------------------------------+-----------+
| Variable_name | Value |
+--------------------------------+-----------+
| innodb_max_dirty_pages_pct | 75.000000 | #脏页在buffer pool中的最大占比
| innodb_max_dirty_pages_pct_lwm | 0.000000 |
+--------------------------------+-----------+
2 rows in set (0.01 sec)

  在内存buffer pool空间允许的范围下,可以调大脏页允许在内存空间的占比,可解燃眉之急,降低写压力。

7、关闭doublewrite降低写压力
mysql> show variables like '%doub%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| innodb_doublewrite | ON |
+--------------------+-------+
1 row in set (0.01 sec)
  两次写特性,默认开启,静态参数。关闭doublewrite适合的场景:
  1、海量DML
  2、不惧怕数据损坏和丢失
  3、系统写负载成为主要负载,关闭doublewrite,降低写压力
注意:
  关于参数调整的生效范围,如何调整(静态参数、动态参数),都是要依据官方文档,依照文档进行调参。

MySQL写压力性能监控与调优的更多相关文章

  1. Java虚拟机性能监控与调优实战

    From:  https://c.m.163.com/news/a/D7B0C6Q40511PFUO.html?spss=newsapp&fromhistory=1 Java虚拟机性能监控与调 ...

  2. <JVM下篇:性能监控与调优篇>补充:浅堆深堆与内存泄露

    笔记来源:尚硅谷JVM全套教程,百万播放,全网巅峰(宋红康详解java虚拟机) 同步更新:https://gitee.com/vectorx/NOTE_JVM https://codechina.cs ...

  3. <JVM下篇:性能监控与调优篇>01-概述篇-02-JVM监控及诊断工具-命令行篇

    笔记来源:尚硅谷JVM全套教程,百万播放,全网巅峰(宋红康详解java虚拟机) 同步更新:https://gitee.com/vectorx/NOTE_JVM https://codechina.cs ...

  4. JAVA性能监控与调优参考文档链接

    JAVA性能监控与调优参考文档链接 jdk8工具集 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/index.htmlTroub ...

  5. Java生产环境下性能监控与调优详解

    1:JVM字节码指令与 javapjavap <options> <classes>cd monitor_tuning/target/classes/org/alanhou/m ...

  6. Java生产环境下性能监控与调优详解视频教程 百度云 网盘

    集数合计:9章Java视频教程详情描述:A0193<Java生产环境下性能监控与调优详解视频教程>软件开发只是第一步,上线后的性能监控与调优才是更为重要的一步本课程将为你讲解如何在生产环境 ...

  7. <JVM下篇:性能监控与调优篇>补充:使用OQL语言查询对象信息

    笔记来源:尚硅谷JVM全套教程,百万播放,全网巅峰(宋红康详解java虚拟机) 同步更新:https://gitee.com/vectorx/NOTE_JVM https://codechina.cs ...

  8. <JVM下篇:性能监控与调优篇>03-JVM监控及诊断工具-GUI篇

    笔记来源:尚硅谷JVM全套教程,百万播放,全网巅峰(宋红康详解java虚拟机) 同步更新:https://gitee.com/vectorx/NOTE_JVM https://codechina.cs ...

  9. Linux系统CPU的性能监控及调优

    前言: 性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢.接口超时,服务器负载高.并发数低,数据库频繁死锁等.尤其是在“糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的 ...

随机推荐

  1. accp8.0转换教材第4章MySQL高级查询(二)理解与练习

    知识点:EXISTS子查询.NOT EXISTS子查询.分页查询.UNION联合查询 一.单词部分 ①exist存在②temp临时的③district区域 ④content内容⑤temporary暂时 ...

  2. Python3中的模块

    模块使用哪种语言实现并不重要,因为所有的模块导入与使用的方式都相同. 1.常用模块导入格式: import importable1,importable2,... import importable ...

  3. 【ALB学习笔记】基于.NET环境的高频RFID卡读写设备的基本操作案例

    基于.NET环境的高频RFID卡读写设备的基本操作案例 广东职业技术学院  欧浩源 1.引言 RFID高频卡在我们的日常生活中随处可见,是物联网应用中不可或缺的一个重要部分,也是全国职业院校技能大赛& ...

  4. 实时音视频互动系列(上):又拍云UTUN网络详解

    如何定义实时音视频互动, 延迟 400ms 内才能无异步感 实时音视频互动如果存在1秒左右的延时会给交流者带来异步感,必须将视频播放延迟限制在400ms以内,才能给用户较好的交互体验. 当延迟控制在4 ...

  5. HashMap的存储原理

    HashMap是java中相当重要的数据结构,使用HashMap的场景非常之多,因此,了解HashMap实现的过程和原理,是非常有必要的,在一些面试中也会经常被问到.好了,我们赶紧来研究java内部是 ...

  6. Kindeditor编辑插件的使用

    1.首先kindeditor这个插件需要配合着asp.net的自生带的控件textbox来实现 2.首先前台界面代码 <f:FormRow runat="server"> ...

  7. [CF337D]邪恶古籍-树状dp

    Problem 邪恶古籍 题目大意 给出一些关键点,求这棵树上到最远关键点距离小于等于d的有多少个. Solution 一个非常简单的树形dp.然而我被这道题给玩坏了. 在经过分析以后,我们发现只需要 ...

  8. 添加zabbix自动发现(监控多tomcat实例)

    说明 何为自动发现?首先我们监控多tomcat实例,如果一个个实例地添加或许可以完成当前需求.但是日后随着实例的增多,再手动一个个去添加就十分不方便了.这时候需要自动发现这个功能,来帮助我们自动添加监 ...

  9. js中的数组排序

    js数组冒泡排序,快速排序的原理以及实现   冒泡排序: 随便从数组中拿一位数和后一位比较,如果是想从小到大排序,那么就把小的那一位放到前面,大的放在后面,简单来说就是交换它们的位置,如此反复的交换位 ...

  10. Android - Fragment (一)定义

    什么是Fragment,为什么要用Fragment? Fragment,直译为碎片.是Android UI的一种. Fragment加载灵活,替换方便.定制你的UI,在不同尺寸的屏幕上创建合适的UI, ...