缓冲池工作原理浅析

Ⅰ、缓冲池介绍

innodb存储引擎缓冲池(buffer pool) ，类似于oracle的sga，里面放着数据页 、索引页 、change buffer 、自适应哈希 、锁(5.5之前)等内容

综上所示：

  • 每次读写数据都是通过Buffer Pool
  • 当Buffer Pool中没有用户所需要的数据时才去硬盘中获取
  • 通过innodb_buffer_pool_size进行设置总容量，该值设置的越大越好

Ⅱ、缓冲池性能问题

2.1 性能线性扩展

假设服务器72核，ht超线程后，144个逻辑核，跑测试按道理144个核应该跑满，如果跑不满，就说明并发有瓶颈，我加核了，却用不上，性能上不去

5.1之前这个问题经常被吐槽，现在不存在这个问题了

1G空间下面如果有65536个page，对这些page进行管理，每次都要对bp加锁(latch),如果bp大了，就有瓶颈，这里说的锁是bp的latch，和数据库的lock不是一回事

qps达到1w，每秒钟要获得至少1w次latch(就看bp的latch，不谈释放和唤醒latch)，开销比较大

核比较多，latch或者并发设计的不好，性能则不能线性扩展 ，而这个bp对于扩展性非常重要，所有的热点的page都在里面，每次访问这些page都要获得bp的latch

2.2 如何提升上述缓冲池性能问题

调整innodb_buffer_pool_instances参数，设置为cpu的数量

默认5.5为1，5.6和5.7是8

假设开始这个值是1，现调整为4，原来1个bp管理65536个页，现在4个bp，每个bp管理16384个页，拆成4个分片，将热点打散，latch变少了，并发性能提升了，这是非常常见的内核层对并发调优的手段，经测试，不调整与调整后性能相差30%

tips:

设置多个缓冲池的时候，必须满足每个池子大于1G才生效，否则，即使my.cnf中设置了innodb_buffer_pool_instances，重启看看是没用的

Ⅲ、buffer pool中热点数据的管理

3.1 buffer pool的组成

缓冲池中的热点是以page为单位来管理，并不是三种List加起来等于总的bp大小，而是Free List + LRU List(Flush List是包含在LRU list里面的)

  • Free List 放空白的page

buffer Pool刚启动时，有一个个16K的空白的页，这些页就存放（链表串联）在Free List中

  • LRU List   包括LRU和unzip_LRU

当读取一个数据页的时候，就从Free List中取出一个页，存入数据，并将该页读到LRU List中

当Free List给一个页给LRU List时，这个过程中需要一个并发控制，也就是之前说的latch，假设现在有两个线程都读到磁盘上这个页，则都需要问Free List来申请空闲页，谁先来先给谁，latch就是对这三个List进行并发控制访问的

  • Flush List包含脏页（数据经过修改，但是未刷入磁盘的页），根据oldest_lsn进行排序

假设被读到的页，马上被更新，这个页就叫脏页，会被放入到Flush List列表中，但只是放了一个指针，而不是实际的页（只要修改过，就放入，不管修改几次）

如何查看缓冲池中的脏页？

SELECT
    pool_id,
    lru_position,
    space,
    page_number,
    table_name,
    oldest_modification,
    newest_modification
FROM
    information_schema.INNODB_BUFFER_PAGE_LRU
WHERE
    oldest_modification <> 0
        AND oldest_modification <> newest_modification;

结果集为空，则表示没有脏页，线上小心，不要乱执行，此sql消耗比较大

tips:

Flush list 中存放的不是一个页，而是页的指针（page number）

小结：

LRU List存放的是所有已经使用的页，里面既有干净页也有脏页，Flush List中只有指向脏页的指针

3.2 查看buffer pool的状态

方法1：show engine innodb status\G

...
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 137428992
Dictionary memory allocated 303387
Buffer pool size   8192     #缓冲池中共8192个page
Free buffers       7772     #空白页(Free List),线上很可能是0
Database pages     420      #在使用的页(LRU List)
Old database pages 0        #LRU中教冷的page
Modified db pages  0        #脏页
Pending reads      0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s    #youngs表示old变为new
Pages read 368, created 52, written 322
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 420, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
...

如果设置了多个buffer pool
找到individual buffer pool info看每一个bp的情况

方法2：看两张元数据表

先说下，这东西比较大，看起来不是很方便，不太推荐

[email protected]) [(none)]> SELECT
    ->     pool_id,
    ->     pool_size,
    ->     free_buffers,
    ->     database_pages,
    ->     old_database_pages,
    ->     modified_database_pages
    -> FROM
    ->     information_schema.innodb_buffer_pool_stats\G
*************************** 1. row ***************************
                pool_id: 0
              pool_size: 8192
           free_buffers: 7772
         database_pages: 420
     old_database_pages: 0
modified_database_pages: 0
1 row in set (0.00 sec)

([email protected]) [(none)]> SELECT
    ->     space, page_number, newest_modification, oldest_modification
    -> FROM
    ->     information_schema.innodb_buffer_page_lru
    -> LIMIT 1\G
*************************** 1. row ***************************
              space: 0
        page_number: 7
newest_modification: 5330181742     #该页最近一次（最新）被修改的LSN值
oldest_modification: 0              #该页在Buffer Pool中第一次被修改的LSN值，FLush List是根据该值进行排序的,该值越小，表示该页应该最先被刷新
1 row in set (0.01 sec)

3.2 LRU算法解析

MySQL中使用了midpoint LRU算法来管理LRU List

  • 当该页被第一次读取时，将该页先放在mid point的位置（因为无法保证一定是活跃）
  • 当被读到第二次时才将改页放入到new page的首部
  • innodb_old_blocks_pct参数控制mid point的位置，默认是37，即3/8的位置

3.3 缓冲池防污染

有一种场景，某个page一下子被扫了n次，但其实他并不是热页，这时候如果按照之前说的，这个page会被放到new里面去，这其实就污染了缓冲池

那什么时候会出现一个page每秒被读n次呢？

scan的时候，select * from tb_name;如果这个page里有10条记录，这个page就会被读10次

我们可以通过将一个page固定在midpoint位置一定的时间来解决这个问题

set global innodb_old_blocks_time=1;

通常 select * 扫描操作不会高于1秒，一个页很快就被扫完了

无论读多少次，在innodb_old_blocks_time的时间内都不管（都视作只读取了一次），等这个时间过去了（时间到），如果该页还是被读取了，才把这个页放到new page的首部，如果设为0，则表示读到第二次就放到new里去

如果开发有个scan操作，就需要设置一下，操作完后再改回来。最好的方案是放到从机上，避免扫描语句污染LRU

tips：

①如果一个page中10条记录一次读，读这十条记录的时候这个页就会被锁成只读，那其他线程对这个页的操作就不被允许了，数据库是一个并发系统，这是不合理的，这样读一个页hold住锁的时间会长，所以是每读一条记录去读一次页，然后马上释放，把读到的位置————游标(这个游标和数据库的游标不是一回事)保存下来，下次再要读的时候，从打开这个游标继续读，但是位置可能会变化，所以会重新去读这个页，以此确保各个线程公平调度

②myisam缓存data是交给操作系统缓存 ，和pg一样

3.4 buffer pool的预热

背景：

在MySQL启动后（MySQL5.6之前），Buffer Pool中页的数据是空的，需要大量的时间才能把磁盘中的页读入到内存中，导致启动后的一段时间性能很差

例：启动的时候load

64GB BP 10M/s读取 100min

预热策略：将LRU列表dump出来，通过较顺序读取的方式预热50M~200M

预热方法：

select count(1) from table force index(primary)

select count(1) from index

说明：

上面两种方法很痤。并没有预热真正的热点数据，只是把数据读进来了,粒度非常粗，比如你数据100G，bp10G，那真正的热点很大部分不是热点数据

网易试过共享内存来做，数据库重启bp不清，不过操作系统重启了也就白搭了

好办法：

MySQL5.6 开始有办法了

([email protected]172.16.0.10) [(none)]> show variables like ‘innodb_buffer_pool%‘;
+-------------------------------------+----------------+
| Variable_name                       | Value          |
+-------------------------------------+----------------+
| innodb_buffer_pool_chunk_size       | 134217728      |
| innodb_buffer_pool_dump_at_shutdown | ON             |    #在停机时dump出buffer pool中的（space,page）
| innodb_buffer_pool_dump_now         | OFF            |    #set一下，表示现在就从buffer pool中dump
| innodb_buffer_pool_dump_pct         | 25             |    #dump的bp的前百分之多少，是每个buffer pool最近使用的页数，而不是整体，可写到[mysqld-5.7]中
| innodb_buffer_pool_filename         | ib_buffer_pool |    #dump出的文件的名字
| innodb_buffer_pool_instances        | 1              |
| innodb_buffer_pool_load_abort       | OFF            |
| innodb_buffer_pool_load_at_startup  | ON             |    #启动时加载dump的文件，恢复到buffer pool中
| innodb_buffer_pool_load_now         | OFF            |    #set一下，表示现在加载 dump的文件
| innodb_buffer_pool_size             | 1879048192     |
+-------------------------------------+----------------+
10 rows in set (0.00 sec)
  • 关闭数据库之前把bp中的space和page_no给dump出来(不是整个bp，5.6还没正式发布的时候就是dump所有)
  • 重启的时候会把dump出来的内容load进bp,dump出来是无序的，load之前根据space和pageno进行排序，load是异步的，返回速度还可以，对bp基本没影响
  • dump的越多，启动的越慢
  • 频繁dump会导致Buffer Pool中的数据越来越少，是因为设置了innodb_buffer_pool_dump_pct，默认25，姜总用的40
  • 如果做了高可用，可以定期dump，然后将该dump的文件传送到slave上，然后直接load（slave上的（Space，Page）和Master上的 大致相同 ）

简单演示一把：

([email protected]) [(none)]> set global innodb_buffer_pool_dump_now = 1;
Query OK, 0 rows affected (0.00 sec)

([email protected]) [(none)]>  show status like ‘Innodb_buffer_pool_dump_status‘;
+--------------------------------+--------------------------------------------------+
| Variable_name                  | Value                                            |
+--------------------------------+--------------------------------------------------+
| Innodb_buffer_pool_dump_status | Buffer pool(s) dump completed at 180302 16:57:45 |
+--------------------------------+--------------------------------------------------+
1 row in set (0.00 sec)

进入数据目录
[[email protected]_0_5_centos data3306]# ll *pool
-rw-r----- 1 mysql mysql 604 Mar  2 16:59 ib_buffer_pool
[[email protected]_0_5_centos data3306]# head ib_buffer_pool
0,568
0,567
0,566
0,565
0,278
0,564
0,563
0,562
164,3
164,2

停止服务
[[email protected]_0_5_centos data3306]# mysqld_multi stop 3306
截取错误日志
2018-03-02T09:01:10.292549Z 0 [Note] InnoDB: Starting shutdown...
2018-03-02T09:01:10.392851Z 0 [Note] InnoDB: Dumping buffer pool(s) to /mdata/data3306/ib_buffer_pool
2018-03-02T09:01:10.393059Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 180302 17:01:10

启动服务，加载热数据
[[email protected]_0_5_centos data3306]# mysqld_multi start 3306
([email protected]) [(none)]> set global innodb_buffer_pool_load_now = 1;
Query OK, 0 rows affected (0.00 sec)

再截取错误日志
2018-03-02T09:06:40.526294Z 0 [Note] InnoDB: Loading buffer pool(s) from /mdata/data3306/ib_buffer_pool
2018-03-02T09:06:40.526487Z 0 [Note] InnoDB: Buffer pool(s) load completed at 180302 17:06:40

tips:

注意一下innodb_buffer_pool_dump_pct这个参数，先看下下面这个流程

([email protected]) [(none)]> set global innodb_buffer_pool_dump_pct=100;
Query OK, 0 rows affected (0.00 sec)

([email protected]) [(none)]> set global innodb_buffer_pool_dump_now = 1;
Query OK, 0 rows affected (0.00 sec)

[[email protected]_0_5_centos data3306]# cat ib_buffer_pool |wc -l
576

([email protected]) [(none)]> set global innodb_buffer_pool_dump_pct=20;
Query OK, 0 rows affected (0.00 sec)

([email protected]) [(none)]> set global innodb_buffer_pool_dump_now = 1;
Query OK, 0 rows affected (0.00 sec)

[[email protected]_0_5_centos data3306]# cat ib_buffer_pool |wc -l
115

看上去没啥问题，但要注意的是，当你有多个缓冲池的时候，比如有4个，每个里面有100个page，它不是整体来dump前百分之25，而是dump每个缓冲池里面最前面的15个page

Ⅳ、异步读

发现全表扫描，如果已经扫了一部分内容，innodb会异步读取这部分内容后面的一部分，即使你没读到，异步读有两种情况，如下：

随机预读
innodb_random_read_ahead
线性预读
innodb_read_ahead_threshold    该参数目前缺省值为0
  • 线性预读放到以extent为单位，而随机预读放到以extent中的page为单位
  • 线性预读是将下一个extent提前读取到buffer pool中，随机预读是将当前extent中的剩余的page提前读取到buffer pool中

原文地址：https://www.cnblogs.com/DataArt/p/10236638.html

时间： 2024-11-07 08:43:36

缓冲池工作原理浅析的相关文章

Kubernetes NetworkPolicy工作原理浅析

Kubernetes能够把集群中不同Node节点上的Pod连接起来,并且默认情况下,每个Pod之间是可以相互访问的.但在某些场景中,不同的Pod不应该互通,这个时候就需要进行访问控制.那么如何实现呢? 简介 ??Kubernetes提供了NetworkPolicy的Feature,支持按Namespace和按Pod级别的网络访问控制.它利用label指定namespaces或pod,底层用iptables实现.这篇文章简单介绍Kubernetes NetworkPolicy在Calico上的工作

OpenVAS漏洞扫描插件工作原理浅析

开始阅读此文之前请安装好OSSIM v4.15OpenVAS釆用***测试原理,利用Scanner模块中的脚本引擎对目标进行安全检测.Openvas的Scanner的扫描性能依赖于同时进行扫描的并发进程数,不同的硬件环境上可设置的最有效并发扫描数各不相同,Openvas的扫描引擎设备可在保证系统稳定的前提下达到最佳的扫描性能,对于大型网络使用标准设备进行部署可大大降低安装和维护成本.脚本引擎根据用户提交的配置与要求,首先对脚本进行加载与调度,按照顺序依次调用脚本并解析执行,实现扫描功能. 0.什

SPI协议及其工作原理浅析

转载自:http://bbs.chinaunix.net/thread-1916003-1-1.html一.概述. SPI, Serial Perripheral Interface, 串行外围设备接口, 是 Motorola 公司推出的一种同步串行接口技术. SPI 总线在物理上是通过接在外围设备微控制器(PICmicro) 上面的微处理控制单元 (MCU) 上叫作同步串行端口(Synchronous Serial Port) 的模块(Module)来实现的, 它允许 MCU 以全双工的同步串

JQuery选择器$()的工作原理浅析

每次申明一个jQuery对象的时候,返回的是jQuery.prototype.init对象,很多人就会不明白,init明明是jQuery.fn的方法啊,实际上这里不是方法,而是init的构造函数,因为js的prototype对象可以实现继承,加上js的对象只是引用不会是拷贝,new jQuery,new jQuery.fn和new jQuery.fn.init的子对象是一样的,只是有没有执行到init的不同.泗阳县民用航空局 当我们使用选择器的时候$(selector,content),就会执行

【Ceph浅析笔记】Ceph的工作原理

本章主要对Ceph的工作原理进行介绍. 寻址过程 如果Client来了一个请求,不管个请求是读还是写都需要先寻址,才能找到数据应该放哪里或者说需要从哪里去. 之前我们说过Ceph的寻址方式是基于计算的,这样就避免的查表,也避免了使用一个单独的元数据服务器. 概述 对于Client传来的一个File,为了方便处理,我们可以将其分割为若干大小相同的小块Object. 然后可以将这些Object映射到OSD上,如果使用一种固定的映射算法,则一个Object每次都会固定的映射到一组OSD上,那么如果这个

【Spark Core】TaskScheduler源码与任务提交原理浅析2

引言 上一节<TaskScheduler源码与任务提交原理浅析1>介绍了TaskScheduler的创建过程,在这一节中,我将承接<Stage生成和Stage源码浅析>中的submitMissingTasks函数继续介绍task的创建和分发工作. DAGScheduler中的submitMissingTasks函数 如果一个Stage的所有的parent stage都已经计算完成或者存在于cache中,那么他会调用submitMissingTasks来提交该Stage所包含的Tas

数据库SQL SELECT查询的工作原理

作为B/S架构的开发人员,总是离不开数据库.一般开发员只会应用SQL的四条经典语句:select,insert,delete,update.但是我从来没有研究过它们的工作原理,这篇我想说一说select在数据库中的工作原理. B/S架构中最经典的话题无非于三层架构,可以大概分为数据层,业务逻辑层和表示层,而数据层的作用一般都是和数据库交互,例如查询记录.我们经常是写好查询SQL,然后调用程序执行SQL.但是它内部的工作流程是怎样的呢?先做哪一步,然后做哪一步等,我想还有大部分朋友和我一样都不一定

数据库连接池的工作原理

对于共享资源,有一个很著名的设计模式:资源池(resource pool).该模式正是为解决资源频繁分配.释放所造成的问题.数据库连接池的基本思想就是为数据库连接建立一个“缓冲池”.预先在缓冲池中放入一定数量的连接,当需要建立数据库连接时,只需要从缓冲池中取出一个了,使用完毕后再放回去.我们可以通过设定连接池最大数来防止系统无尽的与数据库连接.更为重要的是我们可以通过连接池的管理机制监视数据库连接使用数量,使用情况,为系统开发,测试以及性能调整提供依据. 连接池的相关问题分析: 1.并发问题.

Sftp和ftp 区别、工作原理等（服务器被动就是被动模式，PORT模式建立数据传输通道是由服务器端发起的，在PASV模式中，数据传输的通道的建立是由FTP客户端发起的）good

Sftp和ftp over ssh2的区别 最近使用SecureFx,涉及了两个不同的安全文件传输协议: -sftp -ftp over SSH2 这两种协议是不同的.sftp是ssh内含的协议,只要sshd服务器启动了,它就可用,它本身不需要ftp服务器启动.ftp over SSH2则象一个二传手. 1.SFTP的工作模式: 图1显示了SFTP的工作模式,它是作为SSH2的一个子服务工作的. 图 1 SFTP工作模式 2.FTP over SSH2 此协议还是基于ftp协议的.在此协议中SS