这是学习笔记的第 1893 篇文章

我们先来看一下InnoDB的体系结构图。

这个图分为三个部分,上面的是缓存层,中间是线程层,下面是系统文件层。

在每个层里面又会不断的细分,在MySQL里面存储的单位是页,大小是16k。

缓存层是大量的缓存结构,里面大量的数据都是作为缓存,可以提高访问的查取效率。

系统层是相应的数据字典,数据文件和日志文件,其中binlog是MySQL Server层的,放在这里是因为和InnoDB有密切的关系。

其中多线程设计是InnoDB的一大亮点,通过多线程的方式可以把缓存层,系统文件层的操作高效组织起来,使得InnoDB可以提供数据服务。

学习InnoDB需要明确:InnoDB是基于表的存储引擎,明白了这一点,我们后续对InnoDB状态的分析会有本质的差别。

查看InnoDB状态的小技巧

MySQL中如果要查看InnoDB的状态,强烈推荐的方式就是命令show engine innodb status。

对于这个命令,第一段是头部信息,如下:

mysql> show engine innodb status\G

*************************** 1. row *******************

  Type: InnoDB

  Name: 

Status: 

=====================================

2019-02-16 09:42:27 0x7f20b0690700 INNODB MONITOR OUTPUT

=====================================

Per second averages calculated from the last 34 seconds

。。。。

内容包括当前的日期和时间,以及自上次输出以来经过的时长

可以从时间和描述看到这个命令的输出不是实时的结果。

    
当然还有几类查看的方式,比如information_schema中INNODB_XX的数据字典(比如INNODB_BUFFER_POOL_STATS和INNODB_BUFFER_PAGE_LRU)和新版本中的sys schema,里面是可以提供一些InnoDB不同维度的信息,但是相比而言,show engine innodb status命令的输出要丰富的多。 

   
 目前来看似乎没有专门的工具来解读命令 show engine innodb status的输出信息,在没有这些报告工具之前,我们要读取InnoDB的状态毫无疑问是命令的方式来触发,很多时候我们是执行了命令,然后上下翻屏幕去找相应的信息,很显然这些内容我们没有保留下来,show engine innodb status的结果不是实时的,如果要想查看上一次的命令结果该怎么办呢,有一个小技巧。 

    我们是通过mysqld的进程号在系统层面来找到句柄的信息。

首先查看mysqld的进程号。

# ps -ef|grep mysqld|grep -v grep 

root      2122     1  0 19:54 ?        00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/data/mysql --pid-file=/data/mysql/dev01.pid

mysql     2382  2122  0 19:54 ?        00:00:13 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/mysqld.log --pid-file=/data/mysql/dev01.pid --socket=/tmp/mysql.sock

在这里就是找mysqld的进程号,即2382

在操作系统层面我们来看下句柄的信息,可以看到输出了一个列表。

# ll /proc/2382/fd|grep deleted

lrwx------ 1 root root 64 Sep 12 23:29 11 -> /tmp/ibq9KpG4 (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 4 -> /tmp/ibuuKHaH (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 5 -> /tmp/ibET4ZCa (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 6 -> /tmp/ib4nyi5D (deleted)

lrwx------ 1 root root 64 Sep 12 23:29 7 -> /tmp/ib1XzG2A (deleted)

在这么多的文件里,我们看到文件都是序号,会映射到指定目录下面。 

那么那个文件才是我们要找的呢?我们通过lsof来间接印证。 

可以看到会根据lsof的方式来输出句柄信息。 

# lsof -c mysqld|grep deleted

mysqld    2382 mysql    4u   REG              253,0      3942 1576539 /tmp/ibuuKHaH (deleted)

mysqld    2382 mysql    5u   REG              253,0         0 1576540 /tmp/ibET4ZCa (deleted)

mysqld    2382 mysql    6u   REG              253,0         0 1576541 /tmp/ib4nyi5D (deleted)

mysqld    2382 mysql    7u   REG              253,0         0 1576542 /tmp/ib1XzG2A (deleted)

mysqld    2382 mysql   11u   REG              253,0         0 1576543 /tmp/ibq9KpG4 (deleted)

需要注意第7列,这是唯一一个句柄内容非空的,在这个场景里就是show engine innodb status的输出结果,即文件/tmp/ibuuKHaH映射到的4号文件。
 

# ll 4

lrwx------ 1 root root 64 Sep 12 23:29 4 -> /tmp/ibuuKHaH (deleted)

如果要查看命令的完整内容,则需要查看的就是4号文件。

# cat 4

=====================================

2018-09-12 23:28:26 0x7f8e7bf74700 INNODB MONITOR OUTPUT

=====================================

Per second averages calculated from the last 22 seconds

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 6 srv_active, 0 srv_shutdown, 12793 srv_idle

srv_master_thread log flush and writes: 12799

。。。。

后续可以基于这些内容来做更多的定制和解析。 

InnoDB的多线程技术

前面说到了InnoDB是多线程设计,那么在报告中如何体现呢。 

我们需要聊一下InnoDB的后台线程,可以使用如下的脑图来解释

InnoDB的线程主要分为4类,Master Thread,IO Thread,Purge Thread,Page Cleaner Thread

Master Thread是InnoDB的核心线程,早期的很多事情都是它来做的,算是一个全栈线程,后来逐步做了拆分,自MySQL5.5开始引入了purge thread,将purge 任务从master线程中独立出来,自MySQL 5.6.2开始引入了Page cleaner thread.

这些线程的作用和描述如下:

线程

功能描述

相关数据库参数

Master Thread

是核心的后台线程,主要负责异步刷新和数据一致性处理

IO Thread

使用了异步IO模型,负责处理不同类型的IO请求回调

innodb_read_io_threadsinnodb_write_io_threads

Purge Thread

事务提交后回收已经使用并分配的undo页,线程数从1提高到4,加快标记为废弃undo页的回收速度

innodb_purge_threads

Page Cleaner Thread

执行buffer pool里面脏页刷新操作,可以进行调整,默认为1,最大为64

innodb_page_cleaners

可能看到这里还不够清晰,我们可以记住我们的小目标,通过命令来匹配信息:

其中Master Thread的信息在命令输出中如下:

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 21 srv_active, 0 srv_shutdown, 91981 srv_idle

srv_master_thread log flush and writes: 92002

这是一个测试环境的输出结果,没有什么负载,其中srv_master_thread loops是Master线程的循环次数,每次循环时会选择一种状态(active,shutdown,idle)执行,其中Active数量增加与数据变化有关,与查询无关,可以通过srv_active和srv_idle的差异可以看出,通过对比active和idle的值,来获得系统整体负载情况,如果Active的值越大,证明服务越繁忙。

一个相对比较繁忙的数据库的输出如下,可以看到Active的数据远远高于idle:

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 14921578 srv_active, 0 srv_shutdown, 277461 srv_idle

srv_master_thread log flush and writes: 15199037

而对于IO thread相对简单清晰一些,它们都是异步IO请求,在日志里面已经很清楚了,我们可以看到相关的IO线程和数量:

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)

I/O thread 2 state: waiting for completed aio requests (read thread)

I/O thread 3 state: waiting for completed aio requests (read thread)

I/O thread 4 state: waiting for completed aio requests (read thread)

I/O thread 5 state: waiting for completed aio requests (read thread)

I/O thread 6 state: waiting for completed aio requests (write thread)

I/O thread 7 state: waiting for completed aio requests (write thread)

I/O thread 8 state: waiting for completed aio requests (write thread)

I/O thread 9 state: waiting for completed aio requests (write thread)

其中read thread默认4个,write thread默认4个,log thread和insert buffer thread各1个,read和wrtie线程都可以根据参数进行调整。。

对于Purge thread,默认会开启4个线程,提高了回收效率,但是也会带来一些副作用,MySQL对于空间重用机制和Oracle等数据库不同,如果执行了truncate和drop操作,因为开启了多个purge thread去回收空间,随着时间的推移会使得数据恢复的难度大大增加。

而对于Page Cleaner thread,默认值为1,如果在MySQL日志中看到如下的信息,说明我们的Cleaner Thread需要调整一下了。

2019-02-14T23:50:00.501209Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 28469710ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)

技术
©2019-2020 Toolsou All rights reserved,
vue使用THREE.js创建一个可以控制的立方体【JAVA】【华为校园招聘笔试-软件】2020-09-09Vue el-select 获取label值python获取excel的一列或者一行的数据(精华)2020年7月15日 微信小程序 template的使用(精华)2020年7月21日 ASP.NET Core 全局过滤器的使用基于RK3399 PWM驱动开发(精华)2020年6月26日 C#类库 文件读写操作帮助类11-5 指定位置输出字符串Thread.getContextClassLoader与Thread.getClassLoader()区别