【OceanBase诊断调优】—— 4013 内存爆问题的排查

本文介绍 4013 内存爆问题的排查。

内存爆的类型

内存爆主要分为五类，可以通过关键词 OOPS
 确定内存爆的类型。

可以在内存爆的时间点（比如 20230730142424792
），搜索 OOPS
 日志，确定属于哪个类型的内存爆。

grep '\[OOPS\]' observer.log.20230730142424792

租户内存爆

检查是否存在 msg
 信息，表示特定租户的内存爆。

此处 msg
 表示 1008 租户的内存爆了，需要进一步查看该租户下哪个 CTX_ID
 的占用偏高。

1.1 分析租户的内存元信息，确定高内存占用的 CTX_ID

1. 分析租户的内存元信息，确定高内存占用的 CTX_ID
   。

   通过关键词 malloc_allocator.*tenant: 1008
    可以获取租户的内存元信息（limit
   、hold
   、cache_hold
   ），-A 可以显示更多的内存元信息的细节，包括该租户下各 CTX 的内存占用，以及租户线程的 PM 信息。

   

   上述内存元信息显示 DEFAULT_CTX_ID
   、DEFAULT_CTX_ID
   、RPC_CTX_ID
    占用比较高，需要进一步分析这些 CTX_ID
    下占用最高的几个内存模块。

2. CTX 的内存元信息分析

   查找和分析 DEFAULT_CTX_ID
   、DEFAULT_CTX_ID
   、RPC_CTX_ID
    的内存元信息。

   以 DEFAULT_CTX_ID
    举例 。

   

   通过关键词 1008 ctx_id= DEFAULT_CTX_ID
    可以获取 1008 租户的 DEFAULT_CTX_ID
    的内存元信息（hold
   、used
   、limit
   、内存碎片清理信息），-A 可以显示该 CTX_ID
    的各内存模块的内存占用。发现疑似导致内存爆的模块后，找模块 owner
    进行最后的确定。

   CTX_ID
    的内存元信息中 used
   与 hold
    相差很大。

   

   存在二种可能（内存碎片、MEMORY 日志统计延时），可以通过查看内存爆所在的多个时刻的 CTX_ID
    的内存元信息确定。

   

   当无明显占用较大的内存模块的情况

   有明显占用较大的内存模块。

   直接锁定占用最高的内存模块。

• 确定占用最高的几个内存模块是否有已知内存问题未修复。

• 占用最高的几个内存模块，是否有陌生的模块。

• washed_size
   变化幅度很小，可能会出现 used
   大于 hold
   的现象。一般是由内存快速膨胀导致的，需要找到内存膨胀模块。

• 在内存爆所在时间段，搜索 CTX_ID
   的 used
   明显比较大的 MEMORY 日志，跟前后时刻的 MEMORY 日志进行比对，内存占用增幅最大的模块很可能就是内存膨胀模块。

  

• 如果找不到 used
   较大的 MEMROY 日志，需要等待复现（用脚本定时打印该 CTX_ID
   中占用最高的几个内存模块，并且输出 alloc_bytes
   最大的堆栈。

• 内存碎片。

  内存爆触发内存碎片清理机制，washed_size
   会显著变大，hold
   会减小到与 used
   差不多大。

• MEMORY 日志统计延时。

3. kvcache 内存异常。

未发现占用较大的 CTX_ID
，并且租户的大部分内存都是 kvcache，说明租户内存不足时挤占 kvcache 的内存失败了，需要确定失败的原因。

1. 搜索关键词 T1008.*tenant sync wash failed, cache memblock info
   ，其中 ref_count
    不为 2 表示这块内存被应用层 hold 住了，status
    不为 2 表示这块内存正在被 cache 使用。如果存在 ref_count
    和 status
    都为 2 的内存，则说明存在 bug，需要存储方面的分析。

   

2. 搜索关键词 tenant_id.*1008 cache memory info
   ，发现 cache_size
    占用最大的模块，找 owner 分析占用是否符合预期。

   

OBServer 内存爆

• 一般是500租户超卖导致的，可以先获取 500 租户的内存元信息，按照 租户内存爆 这一节的步骤来确定导致 OBServer 内存爆的模块。

• 搜索关键词 CHUNK_MGR
  ，确定 OBServer 是否存在大量缓存，若存在大量缓存则可能是 OBServer 缓存未设上限，导致 OBServer hold 的内存接近 memory_limit
  ，此时申请大于 4M 的内存会失败。可以通过设置配置项 memory_chunk_cache_size
   释放缓存。

• 500 租户的内存占用符合预期，查看全部业务租户的内存元信息。

• 全部业务租户的总 limit
   超过了 memory_limit - system_memory
  ，很可能是租户扩缩容时存在 BUG，或者其他问题。

• 全部业务租户的总 limit
   符合预期，可能是业务租户的规格设置过大，可以适当调小快速恢复业务。

CTX_ID 内存爆

按照 CTX 的内存元信息分析 这一节的步骤来确定导致 OBServer 内存爆的模块。

物理内存耗尽

常见原因是超卖机器的物理内存，一台机器上部署多个 OBServer，或者 OBServer 的 memory_limit
 接近机器的物理内存。可以结合 tsar --mem
 在内存爆时刻的日志进行验证。

无 OOPS 日志

• 通过 CHUNK_MGR
   日志确定是否是 OBServer 内存爆，若是 OBServer 内存爆则按照 OBServer 内存爆 这一节来排查问题。

• 通过全部租户的内存元信息确定是否是租户内存爆，若是，则按照 租户内存爆 这一节来排查问题。

适用版本

OceanBase 数据库所有版本。