can not find enough memory block to wash

适用版本

OceanBase 数据库所有版本。

问题现象及问题原因

-4273 报错表示在 sync wash 过程中发现 cache 中所有的 memblock 都被 pin 了，没有内存可以释放。

解决方法

1. 查看当时 Cache 的大小。

   1. 通过 MEMORY 日志，MEMORY 日志可以看到租户的 cache_hold ，这个字段记录了 Cache 的总大小。

   2. 通过 CACHE 日志，可以看到当时各个 Cache 的大小。

   3. 通过虚拟表 __all_virtual_kvcache_info，各版本都有，但是是实时数据，需要在问题出现时查询。

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

2. 判断是否存在内存泄漏这一步是要区分 cache 是被 pin 住了还是有内存泄漏了。

   对于 OceanBase 数据库 V4.0 及以后版本，可以停止所有查询后尝试手动 flush cache，如果 Cache 能降下来，则说明没有泄漏。手动 flush 需要直连到 OBServer 节点上执行，如果可以 flush 干净 (可能需要手动 flush 多次) ，则表示没有泄漏，对比 flush 前后 __all_virtual_kvcache_info 表中 size 的变化来判断。

   也可以通过查询 __all_virtual_kvcache_store_memblock 虚拟表来直接查看所有 memblock 引用计数，看是否有异常。

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

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

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