MySQL:Innodb page clean 线程 (二) :解析

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

一、数据结构和入口函数

1、数据结构

 ●  page_cleaner_t:整个Innodb只有一个,包含整个page clean线程相关信息。其中包含了一个page_cleaner_slot_t的指针。
变量名 含义
mutex 用于保护整个page_cleaner_t结构体和page_cleaner_slot_t结构体,当需要修改结构体信息的时候需要获取这个mutex,如在pc_request函数中
is_requested 一个条件变量,用于唤醒堵塞在这个条件之上的工作线程
is_finished 一个条件变量,用于通知协调线程刷新工作已经完成
n_workers 当前存在的工作线程总数
requested 布尔值,当前是否需要进行脏数据刷新工作
lsn_limit 需要刷新到lsn的位置,当需要同步刷新的时候,这个值将被赋予,以保证小于这个lsn的日志都已经完成了刷盘工作
n_slots 槽的数量,槽的数量和buffer instance的数量相同
n_slots_requested 当前处于需要刷新状态下(PAGE_CLEANER_STATE_REQUESTED)的槽的数量
n_slots_flushing 当前处于刷新状态下(PAGE_CLEANER_STATE_FLUSHING)的槽的数量
n_slots_finished 当前处于已经刷新完成状态下(PAGE_CLEANER_STATE_FINISHED)的槽的数量
flush_time 整个(以innodb buffer为单位)刷新消耗的时间(累计 page_cleaner->flush_time += ut_time_ms() - tm;)
flush_pass 整个(以innodb buffer为单位)刷新的次数(累计 page_cleaner->flush_pass++;)
slots 指针指向实际的槽
is_running 布尔值,如果关闭innodb会被设置为false,进行强行刷新脏数据
 ●  page_cleaner_slot_t:每个buffer instance都包含一个这样的结构体,page clean工作线程刷新的时候每个线程都会轮询的检测每个槽,直到找到没有被其他page clean线程刷新的槽进行刷新工作或者所有的槽(buffer instance )都刷新完成为止。参考pc_flush_slot函数。
变量名 含义
state 状态PAGE_CLEANER_STATE_REQUESTED、PAGE_CLEANER_STATE_FLUSHING和PAGE_CLEANER_STATE_FINISHED中的一种
n_pages_requested 本槽需要刷新的总的块数量
n_flushed_list 已经刷新的块数
succeeded_list 布尔值,刷新是否完成
flush_list_time 本槽刷新消耗的时间(累计参考pc_flush_slot函数)
flush_list_pass 本槽进行刷新操作的次数(累计参考pc_flush_slot函数)

2、入口函数

 ●  协调工作线程入口:buf_flush_page_cleaner_coordinator

 ●  工作线程入口:buf_flush_page_cleaner_worker

二、主循环解析

其由函数buf_flush_page_cleaner_coordinator实现。实际正常运行情况下的工作都包含在while (srv_shutdown_state == SRV_SHUTDOWN_NONE) 这个大循环下。

1、是否需要睡眠1秒判断

首先如果没有活跃的change buffer 并且没有pending的物理块,并且上次刷新的块数量不为0,则不需要睡眠1秒,源码总有如下解释:

/* The page_cleaner skips sleep if the server is idle and there are no pending IOs in the buffer pool and there is work to do. */

 
if (srv_check_activity(last_activity)
|| buf_get_n_pending_read_ios()
ret_sleep = pc_sleep_if_needed(
|| n_flushed == 0){
if (srv_shutdown_state != SRV_SHUTDOWN_NONE) {
next_loop_time, sig_count); //睡眠一秒 break; }
} else if (ut_time_ms() > next_loop_time) { //如果当前时间大于 上次刷新 时间+1 秒则 设置为OS_SYNC_TIME_EXCEEDED
ret_sleep = OS_SYNC_TIME_EXCEEDED; } else { ret_sleep = 0;
}

但是这个睡眠是可以被唤醒的,比如同步刷新应该就会唤醒它(buf_flush_request_force函数)。参考函数os_event::wait_time_low

2、IO能力不足警告

如前文所描述这里产生如下警告:

page_cleaner: 1000ms intended loop took **ms. The settings might not be optimal.((flushed="**" , during the time.)

源码片段:

 
if (curr_time > next_loop_time + 3000) { //如果刷新时间 大于了 上次时间 +1 秒+3 秒 则报info
if (warn_count == 0) { ib::info() << "page_cleaner: 1000ms"
<< "ms. The settings might not"
" intended loop took " << 1000 + curr_time - next_loop_time
if (warn_interval > 300) {
" be optimal. (flushed=" << n_flushed_last << ", during the time.)";
}
warn_interval = 600; } else {
warn_interval *= 2;
3、同步刷新判断
 ●  触发条件
 
(ret_sleep != OS_SYNC_TIME_EXCEEDED
&& srv_flush_sync
&& buf_flush_sync_lsn > 0)

同步会唤醒正在睡眠状态的page clean协调工作线程那么睡眠应该不会满足一秒的条件所以不会被标记为OS_SYNC_TIME_EXCEEDED,同时srv_flush_sync和buf_flush_sync_lsn均会被设置接下来就是唤醒工作线程进行刷新,同时本协调线程也完成部分任务。

 ●  工作代码
 
pc_request(ULINT_MAX, lsn_limit); //唤醒page clean 工作线程干活
/* Coordinator also treats requests */ //协调者同样要完成部分任务
while (pc_flush_slot() > 0) {}
 ●  唤醒操作

如前文描述在checkpoint或者DML语句执行过程中都会通过log_free_check检查是否redo log处于安全的状态,如果不安全就会调用如下代码(log_preflush_pool_modified_pages函数中)唤醒page clean线程进行同步刷新:

 
if (srv_flush_sync) {
/* wake page cleaner for IO burst */
buf_flush_request_force(new_oldest); //设置全局变量同时通过broadcast唤醒同步刷新
}
buf_flush_wait_flushed(new_oldest); //所有线程等待同步刷新完成

4、活跃刷新

 ●  触发条件
srv_check_activity(last_activity)

这里判断是否有活跃的线程,所谓活跃就是调用srv_inc_activity_count函数进行增加的,一般来讲DML和DDL会标记为活跃,purge线程及其工作线程工作期间会标记为活跃。可以将断点做到srv_inc_activity_count进行debug。所以线上数据库DML比较多所以一般都会是活跃刷新。

 ●  工作代码

这里涉及到刷新多少个块计算主要函数为 page_cleaner_flush_pages_recommendation,后面在讨论。

 
n_to_flush = page_cleaner_flush_pages_recommendation(&lsn_limit, last_pages);
//此处n_to_flush就是本次需要刷新的块数的数量
/* Coordinator also treats requests */ //工作协调线程同样要完成部分任务
pc_request(n_to_flush, lsn_limit); //唤醒page clean 工作线程干活
pc_wait_finished(&n_flushed_list);//等待其他刷新完成
while (pc_flush_slot() > 0) {}

5、空闲刷新

 ●  触发条件
else if (ret_sleep == OS_SYNC_TIME_EXCEEDED)

当睡足了1秒,并且没有活跃的线程。那么就进行空闲刷新,一般来讲如果没有DML/DDL等语句那么应该进行是空闲刷新。

 ●  工作代码
 
buf_flush_lists(PCT_IO(100), LSN_MAX, &n_flushed); //io能力 刷新到那个lsn 以及传出刷新的块数量
//PCT_IO是一个宏如下:
#define PCT_IO(p) ((ulong) (srv_io_capacity * ((double) (p) / 100.0)))

可以看到这里的百分比直接是100%及按照innodb_io_capacity参数的设定进行刷新。

当然这里只是看了正常期间工作的代码,如果是Innodb shutdown也会触发同步刷新。可自行参考代码。

三、page_cleaner_flush_pages_recommendation函数

前面提过这个函数,是活跃刷新刷新块的计算函数,下面直接给出整个代码

 
{
cur_lsn = log_get_lsn();//获取当前的lsn 在 redo buffer中的
if (prev_lsn == 0) { //静态变量如果是0则代表是第一次执行本函数
prev_time = ut_time(); //获取当前时间
/* First time around. */ prev_lsn = cur_lsn; return(0); }
sum_pages += last_pages_in;
if (prev_lsn == cur_lsn) { //如果没有redo日志生成 return(0); } time_t curr_time = ut_time();
((static_cast<double>(sum_pages)
double time_elapsed = difftime(curr_time, prev_time); avg_page_rate = static_cast<ulint>( / time_elapsed)
/* How much LSN we have generated since last call. */
+ avg_page_rate) / 2); //算出上次刷新每秒刷新的pages数量,同时加上次计算的每秒平均刷新块数 然后除以2 得到一个每秒刷新的pages数量 !!!第一个计算条件avg_page_rate 生成 lsn_rate = static_cast<lsn_t>( static_cast<double>(cur_lsn - prev_lsn) / time_elapsed);//计算redo lsn生成率
ulint flush_pass = page_cleaner->flush_pass;
lsn_avg_rate = (lsn_avg_rate + lsn_rate) / 2;//计算redo每秒平均生成率 /* aggregate stats of all slots */ mutex_enter(&page_cleaner->mutex); ulint flush_tm = page_cleaner->flush_time; page_cleaner->flush_time = 0; page_cleaner->flush_pass = 0; ulint list_tm = 0;
mutex_exit(&page_cleaner->mutex);
ulint list_pass = 0; for (ulint i = 0; i < page_cleaner->n_slots; i++) {//扫描所有的槽 page_cleaner_slot_t* slot; slot = &page_cleaner->slots[i]; list_tm += slot->flush_list_time; list_pass += slot->flush_list_pass; slot->flush_list_time = 0; slot->flush_list_pass = 0; }
pct_for_lsn = af_get_pct_for_lsn(age);//计算出lsn的比率 百分比(l列如4.5)
oldest_lsn = buf_pool_get_oldest_modification(); //获取flush list中最老的ls ut_ad(oldest_lsn <= log_get_lsn());//断言 age = cur_lsn > oldest_lsn ? cur_lsn - oldest_lsn : 0; //获取当前LSN和最老LSN的之间的差值 pct_for_dirty = af_get_pct_for_dirty(); //计算出一个刷新百分比 (比如100) !!!!重点 pct_total = ut_max(pct_for_dirty, pct_for_lsn);//取他们的大值
buf_pool_t* buf_pool = buf_pool_from_array(i);
/* Estimate pages to be flushed for the lsn progress *///计算target_lsn ulint sum_pages_for_lsn = 0; lsn_t target_lsn = oldest_lsn + lsn_avg_rate * buf_flush_lsn_scan_factor; //计算下一次刷新的 目标lsn 及target_lsnbuf_flush_lsn_scan_factor是定值3 for (ulint i = 0; i < srv_buf_pool_instances; i++) {//循环整个buffer instance找到小于target_lsn的脏块 ulint pages_for_lsn = 0;
sum_pages_for_lsn += pages_for_lsn; //这里汇总所有 innodb buffer实例中 flush list 小于这个 target lsn 的 page 总数
buf_flush_list_mutex_enter(buf_pool); for (buf_page_t* b = UT_LIST_GET_LAST(buf_pool->flush_list);//每个innodb buffer的末尾的flush list 进行扫描,头插法? b != NULL; b = UT_LIST_GET_PREV(list, b)) { if (b->oldest_modification > target_lsn) { break; } ++pages_for_lsn; //某个 innodb buffer 实例中 flush list 小于这个 target lsn 的 page计数 } buf_flush_list_mutex_exit(buf_pool);
/* Cap the maximum IO capacity that we are going to use by
mutex_enter(&page_cleaner->mutex); ut_ad(page_cleaner->slots[i].state == PAGE_CLEANER_STATE_NONE);//断言所有的槽处于没有刷新状态 page_cleaner->slots[i].n_pages_requested = pages_for_lsn / buf_flush_lsn_scan_factor + 1; //确认槽的n_pages_requested值 mutex_exit(&page_cleaner->mutex); } sum_pages_for_lsn /= buf_flush_lsn_scan_factor;//buf_flush_lsn_scan_factor为定值3
n_pages = (n_pages + avg_page_rate + pages_for_lsn) / 3; // 3部分组成 1、根据参数计算出来的IO能力 2、以往每秒刷新页的数量 3、根据target lsn 计算出来的一个需要刷新的块数
max_io_capacity. Limit the value to avoid too quick increase */ n_pages = PCT_IO(pct_total); //根据 前面得到的 pct_total 和 srv_io_capacity参数得到 刷新的块数 !!!第二个计算参数生成。 if (age < log_get_max_modified_age_async()) { //如果日质量小于 异步刷新的范畴 ulint pages_for_lsn = std::min<ulint>(sum_pages_for_lsn, srv_max_io_capacity * 2); //即便是需要刷新的块数很多,最多只能刷max_io_capacity*2的数量!!!第三个计算参数生成 } if (n_pages > srv_max_io_capacity) {
}
n_pages = srv_max_io_capacity; }
return(n_pages);

此函数最后计算出了需要刷新的块,其中刷新比率计算的的重点函数为af_get_pct_for_dirty和af_get_pct_for_lsn 下面将给出代码注释,其实前文中的算法就来自af_get_pct_for_dirty。

四、af_get_pct_for_dirty和af_get_pct_for_lsn函数

 ●  af_get_pct_for_dirty函数
 
double dirty_pct = buf_get_modified_ratio_pct(); //得到 修改的块/总的块的 的百分比 记住脏数据比率
if (dirty_pct == 0.0) { /* No pages modified */ return(0); }
if (srv_max_dirty_pages_pct_lwm == 0) { //如果innodb_max_dirty_pages_pct_lwm没有设置
ut_a(srv_max_dirty_pages_pct_lwm <= srv_max_buf_pool_modified_pct);
if (dirty_pct >= srv_max_buf_pool_modified_pct) { //如果脏数据比率大于了innodb_max_dirty_pages_pct则返回比率100%
/* The user has not set the option to preflush dirty pages as we approach the high water mark. */
return(100);
/* We have crossed the high water mark of dirty pages In this case we start flushing at 100% of innodb_io_capacity. */ }
/* We should start flushing pages gradually. */ //innodb_max_dirty_pages_pct_lwm参数设置
} else if (dirty_pct >= srv_max_dirty_pages_pct_lwm) { //如果设置了innodb_max_dirty_pages_pct_lwm 并且脏数据比率大于了 return(static_cast<ulint>((dirty_pct * 100)
return(0);//否则返回0
/ (srv_max_buf_pool_modified_pct + 1))); //则返回 (脏数据比率/(innodb_max_dirty_pages_pct+1))*100 也是一个比率 如(45/76)*100 }

 ●  af_get_pct_for_lsn函数:

注意innodb_cleaner_lsn_age_factor参数默认设置为high_checkpoint,可以看到算法最后是除以700.5,所有前文我说这个函数算出来的比率一般比较小。

 
if (age < max_async_age && !srv_adaptive_flushing) { //如果小于异步刷新 且 自适应flush 没有开启
/* We have still not reached the max_async point and
/* If we are here then we know that either:
the user has disabled adaptive flushing. */ return(0); }
2) User may have disabled adaptive flushing but we have reached
1) User has enabled adaptive flushing max_async_age. */
lsn_age_factor = (age * 100) / max_async_age; //比率lsn_age_factor = (本次刷新的日志量/(logtotalsize*(9/10)*(7/8)))
ut_ad(srv_max_io_capacity >= srv_io_capacity); switch ((srv_cleaner_lsn_age_factor_t)srv_cleaner_lsn_age_factor) { case SRV_CLEANER_LSN_AGE_FACTOR_LEGACY:
case SRV_CLEANER_LSN_AGE_FACTOR_HIGH_CHECKPOINT: //innodb_cleaner_lsn_age_factor参数默认设置为high_checkpoint
return(static_cast<ulint>( ((srv_max_io_capacity / srv_io_capacity) * (lsn_age_factor * sqrt((double)lsn_age_factor))) / 7.5)); //430 return(static_cast<ulint>(
* (lsn_age_factor * lsn_age_factor //(10 * (3.3*10*10))/700 =4.3
((srv_max_io_capacity / srv_io_capacity) // ((max_io_cap /io_cap) * (sqrt(lsn_age_factor)*lsn_age_factor*lsn_age_factor))/700.5 * sqrt((double)lsn_age_factor)))
/ 700.5)); //

五、总结

本文只是解释了对于page clean线程的结构和刷新方式,但是真正的刷新工作实际上从pc_flush_slot函数调用才开始,后面非常复杂。


原文发布时间为:2018-11-14

本文作者:重庆八怪

本文来自云栖社区合作伙伴“老叶茶馆”,了解相关信息可以关注“老叶茶馆”。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
SQL 关系型数据库 MySQL
深入解析MySQL的EXPLAIN:指标详解与索引优化
MySQL 中的 `EXPLAIN` 语句用于分析和优化 SQL 查询,帮助你了解查询优化器的执行计划。本文详细介绍了 `EXPLAIN` 输出的各项指标,如 `id`、`select_type`、`table`、`type`、`key` 等,并提供了如何利用这些指标优化索引结构和 SQL 语句的具体方法。通过实战案例,展示了如何通过创建合适索引和调整查询语句来提升查询性能。
208 9
|
1月前
|
存储 关系型数据库 MySQL
double ,FLOAT还是double(m,n)--深入解析MySQL数据库中双精度浮点数的使用
本文探讨了在MySQL中使用`float`和`double`时指定精度和刻度的影响。对于`float`,指定精度会影响存储大小:0-23位使用4字节单精度存储,24-53位使用8字节双精度存储。而对于`double`,指定精度和刻度对存储空间没有影响,但可以限制数值的输入范围,提高数据的规范性和业务意义。从性能角度看,`float`和`double`的区别不大,但在存储空间和数据输入方面,指定精度和刻度有助于优化和约束。
198 5
|
1月前
|
缓存 Java 调度
多线程编程核心:上下文切换深度解析
在现代计算机系统中,多线程编程已成为提高程序性能和响应速度的关键技术。然而,多线程编程中一个不可避免的概念就是上下文切换(Context Switching)。本文将深入探讨上下文切换的概念、原因、影响以及优化策略,帮助你在工作和学习中深入理解这一技术干货。
54 10
|
2月前
|
缓存 监控 Java
Java线程池提交任务流程底层源码与源码解析
【11月更文挑战第30天】嘿,各位技术爱好者们,今天咱们来聊聊Java线程池提交任务的底层源码与源码解析。作为一个资深的Java开发者,我相信你一定对线程池并不陌生。线程池作为并发编程中的一大利器,其重要性不言而喻。今天,我将以对话的方式,带你一步步深入线程池的奥秘,从概述到功能点,再到背景和业务点,最后到底层原理和示例,让你对线程池有一个全新的认识。
66 12
|
1月前
|
调度 开发者
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
68 4
|
1月前
|
算法 调度 开发者
多线程编程核心:上下文切换深度解析
在多线程编程中,上下文切换是一个至关重要的概念,它直接影响到程序的性能和响应速度。本文将深入探讨上下文切换的含义、原因、影响以及如何优化,帮助你在工作和学习中更好地理解和应用多线程技术。
50 4
|
1月前
|
Java 调度 Android开发
安卓与iOS开发中的线程管理差异解析
在移动应用开发的广阔天地中,安卓和iOS两大平台各自拥有独特的魅力。如同东西方文化的差异,它们在处理多线程任务时也展现出不同的哲学。本文将带你穿梭于这两个平台之间,比较它们在线程管理上的核心理念、实现方式及性能考量,助你成为跨平台的编程高手。
|
2月前
|
存储 缓存 监控
Java中的线程池深度解析####
本文深入探讨了Java并发编程中的核心组件——线程池,从其基本概念、工作原理、核心参数解析到应用场景与最佳实践,全方位剖析了线程池在提升应用性能、资源管理和任务调度方面的重要作用。通过实例演示和性能对比,揭示合理配置线程池对于构建高效Java应用的关键意义。 ####
|
2月前
|
存储 安全 Java
Java多线程编程中的并发容器:深入解析与实战应用####
在本文中,我们将探讨Java多线程编程中的一个核心话题——并发容器。不同于传统单一线程环境下的数据结构,并发容器专为多线程场景设计,确保数据访问的线程安全性和高效性。我们将从基础概念出发,逐步深入到`java.util.concurrent`包下的核心并发容器实现,如`ConcurrentHashMap`、`CopyOnWriteArrayList`以及`BlockingQueue`等,通过实例代码演示其使用方法,并分析它们背后的设计原理与适用场景。无论你是Java并发编程的初学者还是希望深化理解的开发者,本文都将为你提供有价值的见解与实践指导。 --- ####
|
1月前
|
NoSQL Redis
单线程传奇Redis,为何引入多线程?
Redis 4.0 引入多线程支持,主要用于后台对象删除、处理阻塞命令和网络 I/O 等操作,以提高并发性和性能。尽管如此,Redis 仍保留单线程执行模型处理客户端请求,确保高效性和简单性。多线程仅用于优化后台任务,如异步删除过期对象和分担读写操作,从而提升整体性能。
67 1

推荐镜像

更多