MySQL · TokuDB · Cachetable 的工作线程和线程池

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: 介绍 TokuDB也有类似InnoDB的buffer pool叫做cachetable,存储数据节点(包括叶节点和中间节点)和rollback段,本文中为了表达简单,叶节点,中间节点和rollback段统称数据节点。Cachetable是全局唯一的,它与MySQL实例存在一一对应的关系。TokuD

介绍

TokuDB也有类似InnoDB的buffer pool叫做cachetable,存储数据节点(包括叶节点和中间节点)和rollback段,本文中为了表达简单,叶节点,中间节点和rollback段统称数据节点。Cachetable是全局唯一的,它与MySQL实例存在一一对应的关系。TokuDB没有采用常见的BTREE(BTREE+,BTREE*)表示索引,而是采用Fractal Tree,简称FT。FT跟BTREE+类似,维护了一个树形的有序结构,中间节点存储pivot(TokuDB的中间节点还包含message buffer),叶节点存储数据。

数据库启动的时候会去初始化cachetable。Client线程(调用栈上下文所在的线程)要访问某个数据节点会首先在cachetable里面查找,找到就立即返回;否则会在cachetable申请一个cache项,然后从磁盘上加载数据到那个cache项。TokuDB里表示cache项的数据结构叫做pair,记录(节点块号/页号,数据节点)的对应关系。在MySQL的缺省引擎InnoDB中,数据和索引是存储在一个文件里的,而TokuDB中每个索引对应一个单独的磁盘文件。

Cachetable是一个hash表,每个bucket里面包含多个pair,共1024*1024个bucket。属于相同索引的pair由cachefile来管理。TokuDB有一个优化在后面会涉及到,这里先简单提一下。当server层显示关闭某个TokuDB表时FT层会调用toku_cachefile_close关闭表或者索引,并把缓存的数据节点从cachetable删除;但这些数据节点仍然保留在cachefile中(保留在内存中)。这种cachefile会被加到的stale列表里面,它包含的数据节点会在内存里呆一段时间。近期再次访问这个索引时,首先会在active列表里查找索引对应的cachefile。若没有找到会尝试在stale列表查找并把找到的cachefile的数据节点重新加到cachetable里去。近期再次访问相同的数据集就不必从磁盘上加载了。

Cachetable的工作线程(worker thead)

Cachetable创建了三个工作线程:

  1. evictor线程:释放部分cachetable内存空间;
  2. cleaner线程:flush中间节点的message buffer到叶节点;
  3. checkpointer线程:写回dirty数据。

Cachetable的线程池

Cachetable创建了三个线程池:

  1. client线程池:帮助cleaner线程flush中间节点的message buffer;
  2. cachetable线程池:
    • 帮助client线程fetch/partial fetch数据节点
    • 帮助evictor线程evict/partial evict数据节点
    • 从cachetable删除时,后台删除数据节点
  3. checkpoint线程池:帮助client线程写回处于checkpoint_pending状态的数据节点。

Cachetable的几个主要队列

  1. m_clock_head:新加载的数据节点除了加入hash方便快速定位,也会加入此队列。可以理解成cachetable的LRU队列;
  2. m_cleaner_head:指向m_clock_head描述LRU队列,cleaner线程从这个位置开始扫描找到memory pressure最大的中间节点发起message buffer flush操作;
  3. m_checkpoint_head:指向m_clock_head描述LRU队列,checkpointer线程在begin checkpoint阶段从这个位置开始扫描,把每个数据节点加到m_pending_head队列;
  4. m_pending_head:checkpointer线程在end checkpoint阶段从这个位置开始扫描,把ditry数据节点写回到磁盘上。

Evictor线程

随着数据逐渐加载到cachetable,其消耗的内存空间越来越大,当达到一定程度时evictor工作线程会被唤醒尝试释放一些数据节点。Evitor线程定期运行(缺省1秒)。Evictor定义四个watermark来评价当前cachetable消耗内存的程度:

  1. m_low_size_watermark: 达到此watermark以后,evictor线程停止释放内存空间。通俗的说,这就是cachetable消耗内存的上限;
  2. m_low_size_hysteresis: 达到此watermark以后,client线程(也就是server层线程)唤醒evictor线程释放内存。一般是m_low_size_watermark的1.1倍;
  3. m_high_size_hysteresis: 达到此watermark以后,阻塞的client线程会被唤醒。一般是m_low_size_watermark的1.2倍;
  4. m_high_size_watermark:达到此watermark以后,client线程会被阻塞在m_flow_control_cond条件变量上等待evictor线程释放内存。一般是m_low_size_watermark的1.5倍。

Evictor线程被唤醒的时机

  1. 添加新pair;
  2. Get pair时,需要fetch或者partial fetch数据节点;
  3. Evictor destroy时,唤醒等待的client线程;
  4. 释放若干数据节点后,Evictor判断是否要继续运行。

铺垫了这么多,下面一起来看一下evictor线程的主体函数run_evictionrun_eviction是一个while循环调用eviction_needed判断是否要进行eviction。如下所示:m_size_current表示cachetable的当前size,m_size_evicting表示当前正在evicting的数据节点消耗的内存空间。两者的差就是这次eviction运行前,cachetable最终能到达的size。
伪码如下:

bool eviction_needed() {
    return (m_size_current - m_size_evicting) > m_low_size_watermark;
}
void run_eviction(){
    uint32_t num_pairs_examined_without_evicting = 0;
    while (eviction_needed()) {
        if (m_num_sleepers > 0 && should_sleeping_clients_wakeup()) {
            /* signal the waiting client threads */
        }
        bool some_eviction_ran = evict_some_stale_pair();
        if (!some_eviction_ran) {
            get m_pl->read_list_lock;
            if (!curr_in_clock) {
                /* nothing to evict */
               break;
            }
            if (num_pairs_examined_without_evicting > m_pl->m_n_in_table) {
                /* everything is in use */
                break;
            }
            bool eviction_run = run_eviction_on_pair(curr_in_clock);
            if (eviction_run) {
                // reset the count
                num_pairs_examined_without_evicting = 0;
            }
            else {
                num_pairs_examined_without_evicting++;
            }
            release m_pl->read_list_lock;
        }
    }
}

eviction_needed 返回true时evictor尝试释放内存。它首先看一下当前的cachetable是否降到m_high_size_hysteresis以下,若是就唤醒等待在m_flow_control_cond条件变量上的client线程。然后,cachetable会先尝试回收stale列表里面cachefile上的数据节点。若stale列表里面没有可回收的数据节点,就会从m_clock_head开始尝试回收内存。对于近期没有被访问过的数据节点,会调用try_evict_pair尝试回收;否则会使之逐渐退化并尝试partial evict。如果把整个m_clock_head队列扫描一遍都没发现可回收的数据节点,那么这次evictor线程的工作就完成了,等下次被唤醒时再次尝试回收内存。

Cleaner线程

Cleaner是另一个定期运行(缺省1秒)的工作线程,从m_cleaner_head开始最多扫8个数据节点,从中找到cache pressure最大的节点(这个过程会skip掉正在被其他线程访问的节点)。由于叶节点和rollback段的cache pressure为0,找到的节点一定是中间节点。如果这个节点设置了checkpoint_pending标记,那么需要先调用write_locked_pair_for_checkpoint把数据写回再调用cleaner_callback把中间节点的message buffer刷到叶节点上去。数据写回的过程,如果节点设置了clone_callback,写回是由checkpoint线程池来完成的;没有设置clone_callback的情况,写回是由cleaner线程完成的。中间节点flush message buffer是一个很复杂的过程,涉及到message apply和merge等操作,打算另写一篇文章介绍。
伪码如下:

run_cleaner(){
    uint32_t num_iterations = get_iterations(); // by default, iteration == 1
    for (uint32_t i = 0; i < num_iterations; ++i) {
        get pl->read_list_lock;
        PAIR best_pair = NULL;
        int n_seen = 0;
        long best_score = 0;
        const PAIR first_pair = m_cleaner_head;
        if (first_pair == NULL) {
            /* nothing to clean */
            break;
        }
        /* pick up best_pair */
        do {
            get m_cleaner_head pair lock;
            skip m_cleaner_head if which was being referenced by others
            n_seen++;
            long score = 0;
            bool need_unlock = false;
            score = m_cleaner_head cache pressure
            if (best_score < score) {
                best_score = score;
                if (best_pair) {
                    need_unlock = true;
                }
                best_pair = m_cleaner_head;
            } else {
                need_unlock = true;
            }
            if (need_unlock) {
                release m_cleaner_head pair lock;
            }
            m_cleaner_head = m_cleaner_head->clock_next;
        } while (m_cleaner_head != first_pair && n_seen < 8);
        release m_pl->read_list_lock;
        if (best_pair) {
            get best_pair->value_rwlock;
            if (best_pair->checkpoint_pending) {
                write_locked_pair_for_checkpoint(ct, best_pair, true);
            }
            bool cleaner_callback_called = false;
            if (best_pair cache pressure > 0) {
                r = best_pair->cleaner_callback(best_pair->value_data, best_pair->key, best_pair->fullhash, best_pair->write_extraargs);
                cleaner_callback_called = true;
            }
            if (!cleaner_callback_called) {
                release best_pair->value_rwlock;
            }
        }
    }
}

Checkpointer线程

Cachetable的脏数据是由checkpointer线程定期(缺省60秒)刷到磁盘上。
Checkpointer线程执行过程分为两个阶段:

begin checkpoint阶段

  1. 为每个active的cache file打for_checkpoint标记;
  2. 写日志;
  3. 为每个数据节点打checkpoint_pending标记,并加到m_pending_head队列;
  4. clone checkpoint_header: FT的metadata在内存中的数据结构是FT_HEADER,这个header有两个版本:
    • h表示当前版本
    • checkpoint_header表示当前正在进行checkpoint的版本,是h在checkpoint开始时刻的副本
  5. clone BTT(block translation table): TokuDB采用BTT记录逻辑页号(blocknum)到文件offset的映射关系。每次刷新数据节点时申请一个未使用的offset,把脏页刷到新的offset位置上,不覆盖老的数据。
    BTT表也采用类似的机制被映射到FT文件不同的offset上。BTT的起始地址记录在FT_HEADER中。checkpoint完成时FT_HEADER会被更新,使新数据生效。用户可以使用checkpoint机制生成backup加速重建数据库的过程。BTT表有三个版本
    • 当前版本(_current)
    • 正在checkpoint的版本(_inprogress)
    • 上次checkpoint的版本(_checkpointed)

end checkpoint阶段

  1. 把m_pending_head队列里的数据节点挨个写回到磁盘。写的时候首先检查是否设置clone_callback方法,如有调用clone_callback生成clone节点,在clone_callback里可能会对叶节点做rebalance操作,clone完成后调用cachetable_only_write_locked_data把cloned pair写回。没有设置clone_callback的情况会直接调用cachetable_write_locked_pair把节点写回。
    伪码如下:

     void write_pair_for_checkpoint_thread (evictor* ev, PAIR p) {
         get p->value_rwlock.write_lock;
         if (p->dirty && p->checkpoint_pending) {
             if (p->clone_callback) {
                 get p->disk_nb_mutex;
                 clone_pair(ev, p);
             } else {
                 cachetable_write_locked_pair(ev, p, true /* for_checkpoint */);
             }
         }
         p->checkpoint_pending = false;
         put p->value_rwlock.write_lock;
         if (p->clone_callback) {
             cachetable_only_write_locked_data(ev, p, true /* for_checkpoint */,
     &attr, true /* is_clone */);
         }
     }
    
  2. 调用checkpoint_userdata
    • 写回BTT的_inprogress版本
    • 写回FT_HEADER的checkpoint_header版本,后面会把checkpoint_header释放掉
  3. 调用end_checkpoint_userdata
    • 释放BTT _checkpointed版本占用的地址空间
    • 把_inprogress版本切换成_checkpointed
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
1月前
|
监控 安全 Java
在 Java 中使用线程池监控以及动态调整线程池时需要注意什么?
【10月更文挑战第22天】在进行线程池的监控和动态调整时,要综合考虑多方面的因素,谨慎操作,以确保线程池能够高效、稳定地运行,满足业务的需求。
104 38
|
28天前
|
Java
线程池内部机制:线程的保活与回收策略
【10月更文挑战第24天】 线程池是现代并发编程中管理线程资源的一种高效机制。它不仅能够复用线程,减少创建和销毁线程的开销,还能有效控制并发线程的数量,提高系统资源的利用率。本文将深入探讨线程池中线程的保活和回收机制,帮助你更好地理解和使用线程池。
52 2
|
1月前
|
Prometheus 监控 Cloud Native
JAVA线程池监控以及动态调整线程池
【10月更文挑战第22天】在 Java 中,线程池的监控和动态调整是非常重要的,它可以帮助我们更好地管理系统资源,提高应用的性能和稳定性。
65 4
|
3月前
|
存储 缓存 Java
什么是线程池?从底层源码入手,深度解析线程池的工作原理
本文从底层源码入手,深度解析ThreadPoolExecutor底层源码,包括其核心字段、内部类和重要方法,另外对Executors工具类下的四种自带线程池源码进行解释。 阅读本文后,可以对线程池的工作原理、七大参数、生命周期、拒绝策略等内容拥有更深入的认识。
143 29
什么是线程池?从底层源码入手,深度解析线程池的工作原理
|
1月前
|
Prometheus 监控 Cloud Native
在 Java 中,如何使用线程池监控以及动态调整线程池?
【10月更文挑战第22天】线程池的监控和动态调整是一项重要的任务,需要我们结合具体的应用场景和需求,选择合适的方法和策略,以确保线程池始终处于最优状态,提高系统的性能和稳定性。
114 2
|
2月前
|
Dubbo Java 应用服务中间件
剖析Tomcat线程池与JDK线程池的区别和联系!
剖析Tomcat线程池与JDK线程池的区别和联系!
116 0
剖析Tomcat线程池与JDK线程池的区别和联系!
|
3月前
|
Java
直接拿来用:进程&进程池&线程&线程池
直接拿来用:进程&进程池&线程&线程池
|
2月前
|
设计模式 Java 物联网
【多线程-从零开始-玖】内核态,用户态,线程池的参数、使用方法详解
【多线程-从零开始-玖】内核态,用户态,线程池的参数、使用方法详解
58 0
|
3月前
|
监控 Java
线程池中线程异常后:销毁还是复用?技术深度剖析
在并发编程中,线程池作为一种高效利用系统资源的工具,被广泛用于处理大量并发任务。然而,当线程池中的线程在执行任务时遇到异常,如何妥善处理这些异常线程成为了一个值得深入探讨的话题。本文将围绕“线程池中线程异常后:销毁还是复用?”这一主题,分享一些实践经验和理论思考。
136 3
|
3月前
|
Java
COMATE插件实现使用线程池高级并发模型简化多线程编程
本文介绍了COMATE插件的使用,该插件通过线程池实现高级并发模型,简化了多线程编程的过程,并提供了生成结果和代码参考。

相关产品

  • 云数据库 RDS MySQL 版
  • 下一篇
    无影云桌面