【OceanBase诊断调优】—— KVCache 排查手册

原文链接:OceanBase分布式数据库-海量数据 笔笔算数

本文介绍 KVcache 相关问题的排查方法。

KVCache 相关概念

在进行排查前,需要了解几个概念。

  • pin

    一个 cache 块 ( memblock ) 被 pin 住,表示它正在被引用。

    cache 的由多个定长的块组成,每个块称为一个 memblock 。每个 memblock 中存放了多个 KV ,使用者通过 KV 指针来读取 KV 。容易理解,在使用指针的过程中,需要保证指针的安全,也即需要 pin 住存放 KV 的 memblock ,保证它不被释放。cache 内部通过引用计数来实现,cache 每向外吐出一个 KV 指针,都要对 KV 所在的 memblock 的引用计数加 1 ( pin 住这个 memblock ) ,当不再使用 KV 指针时,引用计数减 1 。也就是说,当引用计数大于 0 时,说明有人正在读其中的内存,那这个 memblock 就不能被释放,反之如果等于 0 ,则释放是安全的。

    简而言之,如果一个 memblock 被 pin 住,那么它不能被释放。

  • sync wash

    sync wash 指 cache 腾出自身内存给租户使用的过程。 从 1 可知,如果一个 memblock 没有被 pin ,那么它是可以被释放的。sync wash 就是 cache 找到没有被 pin 的 memblock ,释放内存,腾给租户使用。

  • cache 大小无上限

    cache 的大小在一个租户内是无上限的。 为了最大化利用租户内存,在租户内不限制 cache 的大小,理论上 cache 最大可以占满一个租户的内存。但是 cache 的内存比较特殊,在租户需要内存时,会触发 cache 的 sync wash ,腾出内存给租户使用。

常见问题

ret=-4273 can not find enough memory block to wash

首先 4273 不是 cache 的问题,4273 报错表示在 sync wash 过程中发现 cache 中所有的 memblock 都被 pin 了,没有内存可以释放。 导致 4273 的原因可能有:

  • cache 本身已经被榨干了,没有内存可以 wash ,所以就找不到不被 pin 的 memblock。

  • cache 本身还有内存,但是都被 pin 住了,无法 wash 出来;这个原因又分为两种情况:

    • 确实有需要较多 cache 的 SQL 在执行。
    • cache handle 引用计数有泄漏。

排查的思路就是逐步确认是哪个原因导致的 4273 ,步骤如下:

  1. 查看当时 cache 的大小。

    * 通过 MEMORY 日志,memory 日志可以看到租户的 cache_hold ,这个字段记录了 cache 的总大小。
    * 通过 CACHE 日志,可以看到当时各个 cache 的大小。
    * 通过虚拟表 `__all_virtual_kvcache_info`,各版本都有,但是是实时数据,需要在案发时查询。
    

    如果此时 cache 大小很少,说明此时 cache 本身已经被榨干,wash 不出内存符合预期,应该查看当时租户的内存分布,看看其他 mod 是否符合预期,否则进入第二步。

  2. 判断是否存在泄漏。

    这一步是通过查看 cache 的大小能否降下来,来区分是 cache handle 引用计数有泄漏还是确实有需要较多 cache 的 SQL 在执行。

    对于 OceanBase 数据库 V4.0 及以后版本,可以停止所有查询后尝试手动 flush cache ,如果 cache 能降下来,则说明没有泄漏,是确实有需要较多 cache 的 SQL 在执行导致。

    手动 flush 需要直连到 OBServer 节点上执行,如果可以 flush 干净 ( 可能需要手动 flush 多次 ) ,则表示没有泄漏,对比 flush 前后 __all_virtual_kvcache_info 表中 size 的变化来判断。也可以通过查询 __all_virtual_kvcache_store_memblock 虚拟表来直接查看所有 memblock 引用计数,看是否有异常。

    select * from __all_virtual_kvcache_store_memblock where ... order by ref_count desc limit 10;
    

    对于 OceanBase 数据库 V4.0 之前版本,只能通过日志查看在 4273 报错后,cache 的大小是否降下去过,如果能降下去,则说明一定没有泄漏,如果没降下去过,则无法判断。( 因为之前版本手动 flush 并不会立即释放 cache 的内存,而是通过降低其访问热度,通过后台 wash 线程慢慢刷出去。 )

    如果是较多 cache 的 SQL 在执行导致,规避方案是,将 cache 用量较大的操作分散在租户内存压力较小的时候执行,如果仍有报错,尝试对租户内存进行扩容,增大内存。 如果是 cache handle 引用计数有泄漏导致,则需要复现问题,排查泄漏的路径。

cache 占用内存较高

如前文所述,cache 在租户内是无上限的,所以理论上无论 cache 占多大内存,只要能被 sync wash ,就是符合预期的。 判断能否 sync wash 出来需要参考问题 1 中判断 cache 大小能否降下来的方法,能降下来就是能 sync wash 出来。

cache 预热

OceanBase 数据库 V4.0 及以后的版本支持 cache 预热功能,之前版本没有此功能。 为缓解 compaction 后的性能抖动,在 compaction 时会将新生成的微块放入 cache 中,进行预热。 预热并不会将所有新生成的微块都预热进 cache ,而是根据租户的内存情况进行预热。现有策略下,data block cache 使用租户空闲内存的 5% ,index block 使用租户空闲内存的 2% 。 data block 和 index block 按照不同的优先级被预热进 cache ,按照中间层索引树的等级分配不同的优先级,越接近根节点的 block 优先级越高。

wash

cache 腾出自身内存的过程称为 wash ,cache 的 wash 行为分为同步 wash 和异步 wash 两种。 同步 wash 就是上文提到的 sync wash,同步腾出内存,这里不再赘述。 异步 wash 由一个后台 wash 线程完成,wash 线程会定期地根据每个租户的内存压力 ( 包括租户大小、当前 cache 大小、租户当前空闲内存等 ) 计算出租户应该 wash 出的 cache size ,然后再根据每个 memblock 的访问热度从低到高 wash 。如果压力不大,计算结果可能是 0,不做 wash ,可以根据如下日志来判断,如果有则表示 wash 线程异步 wash 了 memblock。

COMMON_LOG(INFO, "Wash memory, ",
            "tenant_id", wash_iter->first,
            "cache_size", tenant_wash_info->cache_size_,
            "lower_mem_limit", tenant_wash_info->lower_limit_,
            "upper_mem_limit", tenant_wash_info->upper_limit_,
            "min_wash_size", tenant_wash_info->min_wash_size_,
            "max_wash_size", tenant_wash_info->max_wash_size_,
            "mem_usage", lib::get_tenant_memory_hold(wash_iter->first),
            "reserve_mem", static_cast<int64_t>((static_cast<double>(tenant_wash_info->upper_limit_)) * tenant_reserve_mem_ratio_),
            "wash_size", tenant_wash_info->wash_size_);

wash 线程的异步 wash 实际上是减去 memblock 原始的引用计数,等待引用计数减为 0 时执行释放,因此:

  • 异步 wash 并不能立即释放 memblock ,需要等待不被 pin 。
  • 如果有引用计数泄漏泄漏,wash 线程一样不能 wash memblock。

手动 flush

手动 flush cache 表示手动清理指定 cache , 命令如下,目前只能在 sys 租户下执行,需要直连要 flush 的 OBServer 节点。

alter system flush kvcache [tenant tenant_name [cache 'cache_name']];

cache_name 可以在 __all_virtual_kvcache_info 中查到,常用的 cache_name 有 :user_block_cache、index_block_cache、user_row_cache、fuse_row_cache、bf_cache。

OceanBase 数据库 V4.0 及以后版本,flush 包含了立即清空的功能,预期情况下,flush 之后 cache 应该是立即被清空(若内存占用太多,flush 只清理一部分内存)。如果发生 4274 的报错,是 cache 较多导致的超时问题,再次 flush 即可。

OceanBase 数据库 V4.0 之前版本,手动 flush 只会清除指定 cache 中 KV 的索引,索引删除后,对应的 KV 就无法再被访问到,其所在的 memblock 的热度就会持续降低,等待 wash 线程将其 wash 出去。

判断手动 flush 是否生效

无论新老版本,手动 flush 一定会清理掉全部的 kv_cnt ,可以观察 flush 前后 kv_cnt 是否清零过来判断手动 flush 是否生效。

select * from __all_virtual_kvcache_info where cache_name = '<cache_name>';

监控 cache handle ,排查引用计数泄漏

OceanBase 数据库 V4.0 及之后版本,如果怀疑或确认 cache 引用计数有泄漏,可以通过如下方法诊断。

  1. binary 需要启用 ENABLE_DEBUG_LOG 编译选项。

  2. 打开监控,指定监控的 cache name 。

    alter system set leak_mod_to_check = 'cache_name';
    
  3. 查看泄漏 backtrace 。

    select * from __all_virtual_kvcache_handle_leak_info where tenant_id = tenant_id order by hold_count desc limit 10;
    

    在 OceanBase 数据库 V4.3 及以后版本虚拟表更名为 __all_virtual_storage_leak_info,并且新增配置项 _storage_leak_check_mod 用于指定泄漏监控的内容。

    这里简单介绍一下监控的实现方法。cache 对外吐出的引用计数都包含在 cache_handle 中,一个 cache_handle hold 住 1 个引用计数,所以在 cache 对外吐出 cache_handle 时,记录一条 backtrace ,在 cache_handle reset 时,消除记录。所以最后遗留下来未释放的 backtrace 很大可能就是泄漏的 backtrace 。

    根据记录方式可以知道,只要当前 cache 外部有 cache_handle ,那就会被记录 backtrace ,所以任何路径在持有 cache_handle 期间都会被记录,需要抓到持有时间过长或不符合预期的堆栈才是泄漏的堆栈。

    如果事先没有开启 cache handle 监控,可以通过 __all_virtual_kvcache_store_memblock 虚拟表简要确认一下问题,这张表会输出当前 server 上所有 memblock 的信息。 (OceanBase 数据库 V 4.3 及以后版本使用新的虚拟表)

    select * from __all_virtual_kvcache_store_memblock where ... order by ref_count desc limit 10;
    

    关注 ref_count 列,这一列表示 memblock 的当前的引用计数,目前当 memblock 没有被引用时,这里拿到的引用计数为 2 ( 初始引用计数为 1 ,查 memblock 信息时需要先加引用计数做保护,因此为 2 ) 。在确保某 memblock 当前不会被 pin 的前提下,ref_count 大于 2 的 memblock 都可以认为有引用计数泄漏。

泄漏检测扩展 (OceanBase 数据库 V4.3 及以后版本)

OceanBase 数据库 V4.3 及以后版本,新增存储层的泄漏检测功能,目前支持的检测内容有 cache handle、io handle、storage iter ,同时,新增配置项 _storage_leak_check_mod 用于配置泄漏检测的内容,有效值分别为 cache_name / all_cache / io_handle / storage_iter ,默认为空串,设定成空串或其他值时,关闭监控。

同时,__all_virtual_kvcache_handle_leak_info 虚拟表更名为 __all_virtual_storage_leak_info

检测步骤使用新的配置和虚拟表即可:

  1. binary 需要启用 ENABLE_DEBUG_LOG 编译选项。

  2. 打开监控,指定监控的内容。

    alter system set _storage_leak_check_mod = 'cache_name' | 'all_cache' | 'io_handle' | 'storage_iter' ;
    
  3. 查看泄漏 backtrace。

    select * from __all_virtual_storage_leak_info where ... order by hold_count desc limit 10;
    
相关推荐
Ai 编码助手3 小时前
MySQL中distinct与group by之间的性能进行比较
数据库·mysql
陈燚_重生之又为程序员3 小时前
基于梧桐数据库的实时数据分析解决方案
数据库·数据挖掘·数据分析
caridle3 小时前
教程:使用 InterBase Express 访问数据库(五):TIBTransaction
java·数据库·express
白云如幻3 小时前
MySQL排序查询
数据库·mysql
萧鼎3 小时前
Python并发编程库:Asyncio的异步编程实战
开发语言·数据库·python·异步
^velpro^3 小时前
数据库连接池的创建
java·开发语言·数据库
荒川之神3 小时前
ORACLE _11G_R2_ASM 常用命令
数据库·oracle
IT培训中心-竺老师3 小时前
Oracle 23AI创建示例库
数据库·oracle
小白学大数据3 小时前
JavaScript重定向对网络爬虫的影响及处理
开发语言·javascript·数据库·爬虫
time never ceases4 小时前
使用docker方式进行Oracle数据库的物理迁移(helowin/oracle_11g)
数据库·docker·oracle