手机上怎么建设网站,专业做pe的网站,wordpress账号邮箱,wordpress自定义注册页面原文链接#xff1a;OceanBase分布式数据库-海量数据 笔笔算数 本文介绍 KVcache 相关问题的排查方法。
KVCache 相关概念
在进行排查前#xff0c;需要了解几个概念。 pin 一个 cache 块 ( memblock ) 被 pin 住#xff0c;表示它正在被引用。 cache 的由多个定长的块组成… 原文链接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 步骤如下 查看当时 cache 的大小。 * 通过 MEMORY 日志memory 日志可以看到租户的 cache_hold 这个字段记录了 cache 的总大小。
* 通过 CACHE 日志可以看到当时各个 cache 的大小。
* 通过虚拟表 __all_virtual_kvcache_info各版本都有但是是实时数据需要在案发时查询。如果此时 cache 大小很少说明此时 cache 本身已经被榨干wash 不出内存符合预期应该查看当时租户的内存分布看看其他 mod 是否符合预期否则进入第二步。 判断是否存在泄漏。 这一步是通过查看 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_castint64_t((static_castdouble(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 引用计数有泄漏可以通过如下方法诊断。 binary 需要启用 ENABLE_DEBUG_LOG 编译选项。 打开监控指定监控的 cache name 。 alter system set leak_mod_to_check cache_name;查看泄漏 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。
检测步骤使用新的配置和虚拟表即可 binary 需要启用 ENABLE_DEBUG_LOG 编译选项。 打开监控指定监控的内容。 alter system set _storage_leak_check_mod cache_name | all_cache | io_handle | storage_iter ;查看泄漏 backtrace。 select * from __all_virtual_storage_leak_info where ... order by hold_count desc limit 10;
