innodb_lru_scan_depth

innodb_lru_scan_depth是5.6新增加的参数,根据 官方文档 描述,它会影响page cleaner线程每次刷脏页的数量,

这是一个每1秒  loop一次的线程。在Innodb内部,这个参数对应变量为srv_LRU_scan_depth,grep了一把,有几个地方会涉及到这个参数

page cleaner 线程  刷脏页的长度,从尾部开始刷 srv_LRU_scan_depth 

LRU 连表由 NEW 与 OLD 区构成

1.buf/buf0lru.cc

buf_LRU_free_from_unzip_LRU_list

从unzip_LRU_list取得空闲块

在扫描bp->unzip_LRU时保证扫描深度不超过srv_LRU_scan_depth,以从其中释放一个压缩块的非压缩页。

在5.5中,则有一个计算公式

distance = 100 + (n_iterations

* UT_LIST_GET_LEN(buf_pool->unzip_LRU)) / 5;

n_iterations越大,表示扫描了多次(或者说一次请求空闲块进入这个函数的次数),值不超过5.

buf_LRU_free_from_common_LRU_list

从通用LRU链上取空闲块 

与上述情况类似,但扫描的是bp->LRU。

这两个函数主要用于从LRU获取空闲块(例如free list已空),均有一个参数scan_all,当为true时,表示扫描全部LRU链表,这时候srv_LRU_scan_depth就不起作用了。

我们知道获取空闲块的入口函数是buf_LRU_get_free_block,之前也做过5.5关于这个函数的分析(见 http://mysqllover.com/?p=387

buf_LRU_get_free_block  取空闲块 函数

在5.6中,如果free list为空,则

>如果有flush在发生,等待完成并重试

>如果buf_pool->try_LRU_scan为true,则扫描srv_LRU_scan_depth深度的LRU,成功则返回空闲快

>如果上一步失败,iteration=1,扫描整个LRU链表

>如果上一步失败,iteration>1,依然扫描整个LRU链表,但sleep 100000us

2.buf/buf0flu.cc:

这里主要是page cleaner线程调用

page cleaner线程

buf_flush_page_cleaner_thread  //page cleaner线程入口

|—>buf_flush_LRU_tail

|–>扫描LRU,调用srv_LRU_scan_depth/PAGE_CLEANER_LRU_BATCH_CHUNK_SIZE()

次buf_flush_LRU函数,每次尝试去处理100个block.

划分成chunk的目的是防止用户线程在请求空闲块时等待时间太长

          srv_LRU_scan_depth/PAGE_CLEANER_LRU_BATCH_CHUNK_SIZE()

          buf_flush_LRU   LRU刷新函数

buf_flush_LRU-> buf_do_LRU_batch

buf_free_from_unzip_LRU_list_batch

从buf_pool->unzip_LRU上把非压缩frame移到bp->free上,如果bp->free的长度大于等于srv_LRU_scan_depth会跳出

 

buf_flush_LRU_list_batch

和上面的类似,但是从bp->LRU上扫描

可见srv_LRU_scan_depth会控制从LRU上清理block并将其放到free list上的扫描深度,不光影响page cleaner线程,也会影响用户线程;

从其作用可以看出,当系统的IO比较空闲的时候,可以适当将这个参数设大,当IO吃紧时,需要适当减小

related bug:

http://bugs.mysql.com/bug.php?id=68481

http://bugs.mysql.com/bug.php?id=68497

related blog:

http://mysqlha.blogspot.com/2013/02/mysql-56-io-bound-update-only-workloads.html


/*******************************************************************//**
Flush and move pages from LRU or unzip_LRU list to the free list.
Whether LRU or unzip_LRU is used depends on the state of the system.
@return number of blocks for which either the write request was queued
or in case of unzip_LRU the number of blocks actually moved to the
free list */
static
ulint
buf_do_LRU_batch(
/*=============*/
    buf_pool_t*    buf_pool,    /*!< in: buffer pool instance */
    ulint        max   )           /*!< in: desired number of blocks in the free_list */
{
    ulint    count = 0;

    if (buf_LRU_evict_from_unzip_LRU(buf_pool)) {
        count += buf_free_from_unzip_LRU_list_batch(buf_pool, max);
    }

    if (max > count) {
        count += buf_flush_LRU_list_batch(buf_pool, max - count);
    }

    return(count);
}
时间: 2024-10-10 01:14:51

innodb_lru_scan_depth的相关文章

innodb_io_capacity &gt;=innodb_lru_scan_depth*inoodb_buffer_pool_instances

innodb_lru_scan_depth:每个缓冲池刷脏页的能力 innodb_io_capacity:  iops inoodb_buffer_pool_instances=8 :缓冲池的个数 .关系:       innodb_io_capacity >= innodb_lru_scan_depth * inoodb_buffer_pool_instances

ORCLE INNODB 博客与 innodb_lru_scan_depth

https://blogs.oracle.com/mysqlinnodb/ http://mysqllover.com/?p=485 •MySQL. MySQL 5.6.10 http://www.mysql.com/downloads/mysql/ •MySQL Doc. MySQL 5.6 Release Notes http://dev.mysql.com/doc/relnotes/mysql/5.6/en/ •MySQL Doc. InnoDB Performance and Scala

Chapter 5 MySQL Server Administration_1

Chapter 5 MySQL Server Administration Table of Contents 5.1 The MySQL Server 5.1.1 Configuring the Server 5.1.2 Server Configuration Defaults 5.1.3 Server Option and Variable Reference 5.1.4 Server Command Options 5.1.5 Server System Variables 5.1.6

InnoDB存储引擎介绍-(4)Checkpoint机制二

原文链接 http://www.cnblogs.com/chenpingzhao/p/5107480.html 一.简介 思考一下这个场景:如果重做日志可以无限地增大,同时缓冲池也足够大,那么是不需要将缓冲池中页的新版本刷新回磁盘.因为当发生宕机时,完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻. 但是这需要两个前提条件:1.缓冲池可以缓存数据库中所有的数据:2.重做日志可以无限增大 因此Checkpoint(检查点)技术就诞生了,目的是解决以下几个问题:1.缩短数据库的恢复时

mysql优化21条

今天一个朋友向我咨询怎么去优化 MySQL,我按着思维整理了一下,大概粗的可以分为21个方向. 还有一些细节东西(table cache, 表设计,索引设计,程序端缓存之类的)先不列了,对一个系统,初期能把下面做完也是一个不错的系统. 1. 要确保有足够的内存 数据库能够高效的运行,最关建的因素需要内存足更大了,能缓存住数据,更新也可以在内存先完成.但不同的业务对内存需要强度不一样,一推荐内存要占到数据的15-25%的比例,特别的热的数据,内存基本要达到数据库的80%大小. 2. 需要更多更快的

MySQL 5.6 &amp; 5.7最优配置文件模板

Inside君整理了一份最新基于MySQL 5.6和5.7的配置文件模板,基本上可以说覆盖90%的调优选项,用户只需根据自己的服务器配置稍作修改即可,如InnoDB缓冲池的大小.IO能力(innodb_buffer_pool_size,innodb_io_capacity).特别注意,这份配置文件不用修改,可以直接运行在MySQL 5.6和5.7的版本下,这里使用了小小的技巧,具体可看配置文件.如果配置参数存在问题,也可以及时反馈Inside君,我们一起成长. 触发Inside君做这件事情的原因

Inondb中的checkpoint

checkpoint主要是为了解决一下问题: 1.缩短数据库的恢复时间 2.缓冲池不够用时,将脏页刷新到磁盘 3.重做日志不可用时,刷新脏页 Innodb引擎使用LSN(log sequence number)来标记日志版本. LSN是占8个字节的数字.每个页都有LSN.重做日志也有LSN.Checkpoint也有LSN. Innodb存储引擎内部有两种checkpoint: 1.sharp checkpoint 发生在数据库关闭时.将所有脏页刷新到磁盘.这是默认的方式,即innodb_fast

MySQL优化---DBA对MySQL优化的一些总结

MySQL优化---DBA对MySQL优化的一些总结 http://blog.163.com/li_hx/blog/static/183991413201572522214601/ 1. 要确保有足够的内存数据库能够高效的运行,最关建的因素需要内存足更大了,能缓存住数据,更新也可以在内存先完成.但不同的业务对内存需要强度不一样,一推荐内存要占到数据的15-25%的比例,特别的热的数据,内存基本要达到数据库的80%大小. 2. 需要更多更快的CPUMySQL 5.6可以利用到64个核,而MySQL

mysql的配置文件适用5.6与5.7

根据inside君的配置文件整理而来. [mysql] port            = 3306 socket          = /data/mysql/3306/mysql_3306.sock default-character-set=utf8 prompt = [\\[email protected]\\h][\\d]>\\_ [mysqld] # basic settings # user=nobody                  #调整为实际user sql_mode =