[转载]innodb 的预读

innodb在io的优化上有个比较重要的特性为预读,innodb以64个page为一个extent,那么innodb的预读是以page为单位还是以extent?

这样就进入了下面的话题:linear read-ahead和randomread-ahead;

为了区分这两种预读的方式,我们可以把linear预读放到以extent为单位,而random 预读放到以extent中的page为单位;

linear 预读着眼于将下一个extent提前读取到buffer pool中,

而random预读着眼于将当前extent中的剩余的page提前读取到buffer pool 中:

linear的预读方式有一个很重要的变量控制是否将下一个extent预读到buffer pool中:innodb_read_ahead_threshold:如果一个extent中的被顺序读取的page超过或者等于该参数变量的,innodb将会异步的将下一个extent读取到buffer pool中,比如该参数的值为30,那么当该extent中有30个pages 被 sequentially的读取,则会触发innodb linear预读,将下一个extent读到内存中;在没有该变量之前,当访问到extent的最后一个page的时候,innodb会决定是否将下一个extent放入到buffer pool中;

该参数可以动态的修改:

[email protected](none) 09:20:02>set global innodb_read_ahead_threshold=40;

Query OK, 0 rows affected (0.00 sec)

random的预读方式则是表示当同一个extent中的一些page在buffer pool中发现时,innodb会将该extent中的剩余page一并读到buffer pool中,由于random的预读方式给innodb code带来了一些不必要的复杂性,同时在性能也存在不稳定性,在5.5中已经将这种预读方式废弃。

在监控innodb的预读时候,我们可以通过show innodb status中的 Pages read ahead和evicted without access 两个值来观察预读的情况:

或者通过两个状态值:

Innodb_buffer_pool_read_ahead 和 Innodb_buffer_pool_read_ahead_evicted.

Innodb_buffer_pool_read_ahead:表示通过预读请求到buffer pool的pages;

Innodb_buffer_pool_read_ahead_evicted:表示由于请求到buffer pool中没有被访问,而驱逐出buffer pool的pages;

[email protected](none) 10:19:42>show global status like ‘%read_ahead%’;

+—————————————+———+

| Variable_name | Value |

+—————————————+———+

| Innodb_buffer_pool_read_ahead | 775378 |

| Innodb_buffer_pool_read_ahead_evicted | 1888537 |

而通过show innodb status得到的 Pages read ahead 和evicted without access 则表示每秒读入和读出的pages;

Pages read ahead 1.00/s, evicted without access 9.99/s.

ref:

时间: 2024-11-03 22:37:21

[转载]innodb 的预读的相关文章

关于MySQL buffer pool的预读机制

预读机制 两种预读算法 1.线性预读 2.随机预读 对预读的监控 一.预读机制 InnoDB在I/O的优化上有个比较重要的特性为预读,预读请求是一个i/o请求,它会异步地在缓冲池中预先回迁多个页面,预计很快就会需要这些页面,这些请求在一个范围内引入所有页面.InnoDB以64个page为一个extent,那么InnoDB的预读是以page为单位还是以extent? 数据库请求数据的时候,会将读请求交给文件系统,放入请求队列中:相关进程从请求队列中将读请求取出,根据需求到相关数据区(内存.磁盘)读

Linux内核模块编程与内核模块LICENSE -《详解(第3版)》预读

Linux内核模块简介 Linux内核的整体结构已经非常庞大,而其包含的组件也非常多.我们怎样把需要的部分都包含在内核中呢?一种方法是把所有需要的功能都编译到Linux内核.这会导致两个问题,一是生成的内核会很大,二是如果我们要在现有的内核中新增或删除功能,将不得不重新编译内核. 有没有一种机制使得编译出的内核本身并不需要包含所有功能,而在这些功能需要被使用的时候,其对应的代码被动态地加载到内核中呢?Linux提供了这样的一种机制,这种机制被称为模块(Module).模块具有这样的特点. 模块本

物理读,逻辑读,预读

在使用SET STATISTICS IO ON语句统计I/O时候,我们会看到类似下面的结果: 扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次. 那么它们代表什么呢? 预读:用于估计信息,去硬盘读取数据到缓存. 物理读:查询计划生成好以后,如果缓存缺少所需要的数据,让缓存再次去读硬盘.如果内存里没有缓存数据或执行计划(sql语句改变执行计划不能重用,需要重新计算执行计划),那么SQLSERVER就要去硬盘读取

mongodb优化预读

1.优化预读采用LINUX的BLOCKDEV命令来把预读大小设置小一点,减少内存中无用数据占用,从而优化IO性能RA代表预读大小(扇区),推荐数值是16到32,如文档较小,预读数值可以小一点,修改后mongodb重启才能生效. 预读默认256个扇区,大小为128K mongodb很多都是随机访问,readhead要设置小一点.比如只要读10k,但读了128K [email protected]:~# blockdev --reportRO    RA   SSZ   BSZ   StartSec

初谈SQL Server逻辑读、物理读、预读

前言 本文涉及的内容均不是原创,是记录自己在学习IO.执行计划的过程中学习其他大牛的博客和心得并记录下来,之所以想写下来是为了记录自己在追溯的过程遇到的几个问题,并把这些问题弄清楚. 本章最后已贴出原文地址. 1.SQL Server的数据存储方式 要理解逻辑读.物理读.预读这三个概念,先要搞懂SQL Server的数据存储方式. SQL Server数据库包括数据文件和日志文件,一个数据库可以有一个或多少数据文件.日志文件.所有的数据存储在数据文件中,数据文件可以划分为再小的单元,我们称为“页

SQL Server逻辑读、预读和物理读

SQL Server数据存储的形式 预读:用估计信息,去硬盘读取数据到缓存.预读100次,也就是估计将要从硬盘中读取了100页数据到缓存. 物理读:查询计划生成好以后,如果缓存缺少所需要的数据,让缓存再次去读硬盘.物理读10页,从硬盘中读取10页数据到缓存. 逻辑读:从缓存中取出所有数据.逻辑读100次,也就是从缓存里取到100页数据. SQL Server存储的最小单位是页,每一页大小为8K,SQL Server对于页的读取是原子性的,要么读完一页,要么完全不读.即使是仅仅要获得一条数据,也要

sqlserver性能调优中的逻辑读,物理读,预读是什么意思

表 'T_EPZ_INOUT_ENTRY_DETAIL'.扫描计数 1,逻辑读 4825 次,物理读 6 次,预读 19672 次.SQL SERVER 数据库引擎当遇到一个查询语句时,SQL SERVER数据库引擎会分别生成执行计划(占用CPU和内存资源),同时存储引擎读取 IAM 以生成必须要读取的磁盘地址排序列表.这使 SQL Server 得以将其 I/O 优化为大型有序读取,根据它们在磁盘上的位置按顺序完成.磁盘中取得需要取的数据(占用I/O资源,这就是预读),注 意,两个步骤是并行的

SQL Server逻辑读-预读-物理读

SQL Server逻辑读-预读-物理读    SQL Server 存储数据的方式        1.页是最小的操作单元,也就是说从磁盘读取数据库的时候最少读取一页,每一页的大小是8KB,SQL SERVER对于页的读取是原子性,要么读完一页,要么完全不读,不会有中间状态 2.区是8个连续的页组成的,区是最小的分配单元,当需要空间时最少分配一个区的空间. 看图说话,两个表的结构完全一样,一个插入四条数据,另一个插入100条数据,结果大小都为0.008: SQL SERVER一页的总大小为:8K

Linux内核的文件预读readahead

Linux的文件预读readahead,指Linux系统内核将指定文件的某区域预读进页缓存起来,便于接下来对该区域进行读取时,不会因缺页(page fault)而阻塞.因为从内存读取比从磁盘读取要快很多.预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间,是改进磁盘读I/O性能的重要优化手段之一. 维基百科上关于readhead的介绍资料: readahead is a system call of the Linux kernel that loads a file's content