这是学习笔记的第 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.)