MySQL · 源码分析 · InnoDB LRU List刷脏改进之路

之前的一篇内核月报MySQL · 引擎特性 · InnoDB Buffer Pool 中对InnoDB Buffer pool的整体进行了详细的介绍。文章已经提到了LRU List以及刷脏的工作原理。本篇文章着重从MySQL 5.7源码层面对LRU List刷脏的工作原理,以及Percona针对MySQL LRU Flush的一些性能问题所做的改进,进行一下分析。

在MySQL中,如果当前数据库需要操作的数据集比Buffer pool中的空闲页面大的话,当前Buffer pool中的数据页就必须进行脏页淘汰,以便腾出足够的空闲页面供当前的查询使用。如果数据库负载太高,对于空闲页面的需求超出了page cleaner的淘汰能力,这时候是否能够快速获取空闲页面,会直接影响到数据库的处理能力。我们将从下面三个阶段来看一下MySQL以及Percona对LRU List刷脏的改进过程。

众所周知,MySQL操作任何一个数据页面都需要读到Buffer pool进行才会进行操作。所以任何一个读写请求都需要从Buffer pool来获取所需页面。如果需要的页面已经存在于Buffer pool,那么直接利用当前页面进行操作就行。但是如果所需页面不在Buffer pool,比如UPDATE操作,那么就需要从Buffer pool中新申请空闲页面,将需要读取的数据放到Buffer pool中进行操作。那么官方MySQL 5.7.4之前的版本如何从buffer pool中获取一个页面呢?请看如下代码段:


buf_block_t*
buf_LRU_get_free_block(
/*===================*/
 buf_pool_t* buf_pool) /*!< in/out: buffer pool instance */
{
 buf_block_t* block = NULL;
 bool freed = false;
 ulint n_iterations = 0; 
 ulint flush_failures = 0; 
 bool mon_value_was = false;
 bool started_monitor = false;

 MONITOR_INC(MONITOR_LRU_GET_FREE_SEARCH);
loop:
 buf_pool_mutex_enter(buf_pool); // 这里需要对当前buf_pool使用mutex,存在锁竞争 // 当前函数会检查一些非数据对象,比如AHI, lock 所占用的buf_pool是否太高并发出警告
 buf_LRU_check_size_of_non_data_objects(buf_pool);

 /* If there is a block in the free list, take it */
 block = buf_LRU_get_free_only(buf_pool);

 // 如果获取到了空闲页面,清零之后就直接使用。否则就需要进行LRU页面淘汰 if (block != NULL) {

 buf_pool_mutex_exit(buf_pool);
 ut_ad(buf_pool_from_block(block) == buf_pool);
 memset(&block->page.zip, 0, sizeof block->page.zip);

 if (started_monitor) {
 srv_print_innodb_monitor =
 static_cast<my_bool>(mon_value_was);
 }

 block->skip_flush_check = false;
 block->page.flush_observer = NULL;
 return(block);
 }

 MONITOR_INC( MONITOR_LRU_GET_FREE_LOOPS );

 freed = false;
 /**
 这里会重复进行空闲页扫描,如果没有空闲页面,会根据LRU list对页面进行淘汰。
 这里设置buf_pool->try_LRU_scan是做了一个优化,如果当前用户线程扫描的时候
 发现没有空闲页面,那么其他用户线程就不需要进行同样的扫描。
 */ if (buf_pool->try_LRU_scan || n_iterations > 0) {
 /* If no block was in the free list, search from the
 end of the LRU list and try to free a block there.
 If we are doing for the first time we'll scan only
 tail of the LRU list otherwise we scan the whole LRU
 list. */
 freed = buf_LRU_scan_and_free_block(
 buf_pool, n_iterations > 0);

 if (!freed && n_iterations == 0) {
 /* Tell other threads that there is no point
 in scanning the LRU list. This flag is set to
 TRUE again when we flush a batch from this
 buffer pool. */
 buf_pool->try_LRU_scan = FALSE;
 }
 }

 buf_pool_mutex_exit(buf_pool);

 if (freed) {
 goto loop;
 }

 if (n_iterations > 20
 && srv_buf_pool_old_size == srv_buf_pool_size) {
	// 如果循环获取空闲页的次数大于20次,系统将发出报警信息
 ...
}
 /* If we have scanned the whole LRU and still are unable to
 find a free block then we should sleep here to let the
 page_cleaner do an LRU batch for us. */ if (!srv_read_only_mode) {
 os_event_set(buf_flush_event);
 }

 if (n_iterations > 1) {

 MONITOR_INC( MONITOR_LRU_GET_FREE_WAITS );
	// 这里每次循环释放空闲页面会间隔10ms
 os_thread_sleep(10000);
 }

 /* 如果buffer pool里面没有发现可以直接替换的页面(所谓直接替换的页面,
 是指页面没有被修改, 也没有别的线程进行引用,同时当前页已经被载入buffer pool),
 注意:上面的页面淘汰过程至少会尝试
 innodb_lru_scan_depth个页面。如果上面不存在可以淘汰的页面。那么系统将尝试淘汰一个
 脏页面(可替换页面或者已经被载入buffer pool的脏页面)。
 */ if (!buf_flush_single_page_from_LRU(buf_pool)) {
 MONITOR_INC(MONITOR_LRU_SINGLE_FLUSH_FAILURE_COUNT);
 ++flush_failures;
 }

 srv_stats.buf_pool_wait_free.add(n_iterations, 1);

 n_iterations++;

 goto loop;
}



从上面获取一个空闲页的源码逻辑可以看出,buf_LRU_get_free_block会循环尝试去淘汰LRU list上的页面。每次循环都会去访问free list,查看是否有足够的空闲页面。如果没有将继续从LRU list去淘汰。这样的循环在负载比较高的情况下,会加剧对free list以及LRU list的mutex竞争。

MySQL空闲页面的获取依赖于page cleaner的刷新能力,如果page cleaner不能即时的刷新足够的空闲页面,那么系统就会使用上面的逻辑来为用户线程申请空闲页面。但如果让page cleaner加快刷新,又会导致频繁刷新脏数据,引发性能问题。 为了改善系统负载太高的情况下,page cleaner刷脏能力不足,进而用户线程调用LRU刷脏导致锁竞争加剧影响数据库性能,Percona对此进行了改善,引入独立的线程负责LRU list的刷脏。目的是为了让独立线程根据系统负载动态调整LRU的刷脏能力。由于LRU list的刷脏从page cleaner线程中脱离出来,调整LRU list的刷脏能力不再会影响到page cleaner。下面我们看一下相关的源码:

/**
 该函数会根据系统的负载情况,或者是buffer pool的空闲页面的情况来动态调整lru_manager_thread的 刷脏能力。
*/ static void lru_manager_adapt_sleep_time(
/*==============================*/
 ulint* lru_sleep_time) /*!< in/out: desired page cleaner thread sleep
 time for LRU flushes */ {
 /* 实际的空闲页 */
 ulint free_len = buf_get_total_free_list_length();
 /* 期望至少保持的空闲页 */
 ulint max_free_len = srv_LRU_scan_depth * srv_buf_pool_instances;

 /* 下面的逻辑会根据当前的空闲页面与期望的空闲页面之间的比对,
 来调整lru_manager_thread的刷脏频率
 */ if (free_len < max_free_len / 100) {

 /* 实际的空闲页面小于期望的1%,系统会触使lru_manager_thread不断刷脏。*/
 *lru_sleep_time = 0;
 } else if (free_len > max_free_len / 5) {

 /* Free lists filled more than 20%, sleep a bit more */
 *lru_sleep_time += 50;
 if (*lru_sleep_time > srv_cleaner_max_lru_time) {
 *lru_sleep_time = srv_cleaner_max_lru_time;
 }
 } else if (free_len < max_free_len / 20 && *lru_sleep_time >= 50) {

 /* Free lists filled less than 5%, sleep a bit less */
 *lru_sleep_time -= 50;
 } else {

 /* Free lists filled between 5% and 20%, no change */
 }
}

extern "C" UNIV_INTERN
os_thread_ret_t
DECLARE_THREAD(buf_flush_lru_manager_thread)(
/*==========================================*/ void* arg __attribute__((unused)))
 /*!< in: a dummy parameter required by
 os_thread_create */ {
 ulint next_loop_time = ut_time_ms() + 1000;
 ulint lru_sleep_time = srv_cleaner_max_lru_time;

#ifdef UNIV_PFS_THREAD
 pfs_register_thread(buf_lru_manager_thread_key);
#endif /* UNIV_PFS_THREAD */ #ifdef UNIV_DEBUG_THREAD_CREATION fprintf(stderr, "InnoDB: lru_manager thread running, id %lu\n",
 os_thread_pf(os_thread_get_curr_id()));
#endif /* UNIV_DEBUG_THREAD_CREATION */

 buf_lru_manager_is_active = true;
 /* On server shutdown, the LRU manager thread runs through cleanup
 phase to provide free pages for the master and purge threads. */ while (srv_shutdown_state == SRV_SHUTDOWN_NONE
 || srv_shutdown_state == SRV_SHUTDOWN_CLEANUP) {
 /* 根据系统负载情况,动态调整lru_manager_thread的工作频率 */
 lru_manager_sleep_if_needed(next_loop_time);

 lru_manager_adapt_sleep_time(&lru_sleep_time);

 next_loop_time = ut_time_ms() + lru_sleep_time;

 /**
 这里lru_manager_thread轮询每个buffer pool instances,尝试从LRU的尾部开始淘汰 innodb_lru_scan_depth个页面
 */
 buf_flush_LRU_tail();
 }

 buf_lru_manager_is_active = false;

 os_event_free(buf_lru_event);
 /* We count the number of threads in os_thread_exit(). A created
 thread should always use that to exit and not use return() to exit. */
 os_thread_exit(NULL);

 OS_THREAD_DUMMY_RETURN;
}

从上面的源码可以看到,LRU list的刷脏依赖于LRU_mangager_thread, 当然正常的page cleaner也会对LRU list进行刷脏。但是整个Buffer pool的所有instances都依赖于一个LRU list刷脏线程,负载比较高的情况下也很有可能成为瓶颈。

官方MySQL 5.7版本为了缓解单个page cleaner线程进行刷脏的压力,在5.7.4中引入了multiple page cleaner threads这个feature,用来增强刷脏速度,但是从下面的测试可以发现,即便是multiple page cleaner threads在高负载的情况下,还是会对系统性能有影响。下面的测试结果也显示了性能方面受到的影响。

MySQL · 源码分析 · InnoDB LRU List刷脏改进之路

就multiple page cleaner刷脏能力受到限制,主要是因为存在以下问题: 1) LRU List刷脏在先,Flush list的刷脏在后,但是是互斥的。也就是说在进Flush list刷脏的时候,LRU list不能继续去刷脏,必须等到下一个循环周期才能进行。 2) 另外一个问题就是,刷脏的时候,page cleaner coodinator会等待所有的page cleaner线程完成之后才会继续响应刷脏请求。这带来的问题就是如果某个buffer pool instance比较热的话,page cleaner就不能及时进行响应。

针对上面的问题,Percona改进了原来的单线程LRU list刷脏的方式,继续将LRU list独立于page cleaner threads并将LRU list单线程刷脏增加为多线程刷脏。page cleaner只负责flush list的刷脏,lru_manager_thread只负责LRU List刷脏。这样的分离,可以使得LRU list刷脏和Flush List刷脏并行执行。看一下修改之后的测试情况:

MySQL · 源码分析 · InnoDB LRU List刷脏改进之路

下面用Multiple LRU list flush threads的源码patch简单介绍一下Percona所做的更改。

@@ -2922,26 +2876,12 @@ pc_flush_slot(void)
 } 
 
 if (!page_cleaner->is_running) {
- slot->n_flushed_lru = 0;
 slot->n_flushed_list = 0; 
 goto finish_mutex;
 } 
 
 mutex_exit(&page_cleaner->mutex);
 
/* 这里的patch可以看出LRU list的刷脏从page cleaner线程里隔离开来 */
- lru_tm = ut_time_ms();
-
- /* Flush pages from end of LRU if required */
- slot->n_flushed_lru = buf_flush_LRU_list(buf_pool);
-
- lru_tm = ut_time_ms() - lru_tm;
- lru_pass++;
-

@@ -1881,6 +1880,13 @@ innobase_start_or_create_for_mysql(void)
 NULL, NULL);
 }
/* 这里在MySQL启动的时候,会同时启动和Buffer pool instances同样数量的LRU list刷脏线程。 */
+ for (i = 0; i < srv_buf_pool_instances; i++) {
/* 这里每个LRU list线程负责自己对应的Buffer pool instance的LRU list刷脏 */
+ os_thread_create(buf_lru_manager, reinterpret_cast<void *>(i),
+ NULL);
+ }
+
+ buf_lru_manager_is_active = true;
+

综上所述,本篇文章主要从源码层面对Percona以及官方对于LRU list刷脏方面所做的改进进行了分析。Percona对于LRU list刷脏问题做了很大的贡献。从测试结果可以看到,如果负载较高,空闲页不足的情况下,Percona的改进起到了明显的作用。

上一篇:MySQL · 源码分析 · Innodb 引擎Redo日志存储格式简介


下一篇:MySQL · 引擎分析 · InnoDB行锁分析