OCP 租户监控中 active 比 total 还大， 是 BUG 吗？

OceanBase 技术问题
#1

问题现象：

租户在做大批量数据修改，监控里提示 active 内存 比 total 内存还大， 这个不好理解

image
image851×306 39.9 KB

刚开始还以为是 OCP BUG，后来查看 OB 视图发现数据就是这样。

select  tenant_id, svr_ip, round(active_span/1024/1024/1024,2) active_gb, round(freeze_trigger/1024/1024/1024,2) freeze_trg_gb, freeze_cnt, round(memstore_used/1024/1024/1024,2) memstore_used_gb, round(memstore_limit/1024/1024/1024,2) memstore_limit_gb
from oceanbase.gv$ob_memstore
where tenant_id=1002
;
tenant_id svr_ip active_gb freeze_trg_gb freeze_cnt memstore_used_gb memstore_limit_gb
1002 10.0.0.68 1.73 2.23 32 0.13 3.50
1002 10.0.0.199 0.58 2.23 35 0.13 3.50
1002 10.0.0.198 1.03 2.23 35 0.13 3.50

视图解释

以下是 OB 文档大模型给出的解释： OceanBase AI 助手 - 智能搜索

gv$ob_memstore 视图用于展示所有服务器上所有租户的 MEMTable 的内存使用状况。以下是该视图的主要字段解释：

  1. TENANT_ID：租户的唯一标识符。
  2. SVR_IP：服务器的 IP 地址。
  3. SVR_PORT：服务器的端口号。
  4. ACTIVE_MEMSTORE_USED：当前活跃的 MEMStore 内存使用量。
  5. TOTAL_MEMSTORE_USED：总的 MEMStore 内存使用量。
  6. FREEZE_CNT：MEMStore 的冻结次数。
  7. MEMSTORE_LIMIT：MEMStore 的内存限制。
  8. TOTAL_LIMIT：总的内存限制。

通过查询 gv$ob_memstore 视图，可以监控和分析租户的 MEMStore 内存使用情况，帮助排查内存长时间未释放的问题。

总的内存比活跃的内存还大，活跃的内存不算总的内存吗？看图里在之前很长一段范围，二者又是相等的。这个怎么解释？@论坛小助手

不是某个特定版本的问题，应该是很多版本的问题。上面是 4.2.1.8 。

#3

@论坛小助手

#4

根据您提供的信息和查询结果，active_gb（活跃的 MemStore 内存使用量）确实大于 memstore_limit_gb（MemStore 的内存限制），这看起来确实有些异常。不过，我们需要更详细地了解这些字段的具体含义和统计方式来做出准确的判断。

字段解释

  1. ACTIVE_SPAN (active_gb): 当前活跃的 MemStore 内存使用量。
  2. FREEZE_TRIGGER (freeze_trg_gb): 触发冻结的内存阈值。
  3. FREEZE_CNT: MemStore 的冻结次数。
  4. MEMSTORE_USED (memstore_used_gb): 当前已使用的 MemStore 内存。
  5. MEMSTORE_LIMIT (memstore_limit_gb): MemStore 的内存限制。

可能的原因

  1. 统计延迟:

    • ACTIVE_SPAN 和 MEMSTORE_LIMIT 的统计可能存在延迟。在某些情况下，活跃内存的统计可能会暂时超过限制，尤其是在大量数据写入时。

  2. 内存回收:

    • MemStore 的内存回收机制可能还没有完成。当 MemStore 达到冻结阈值时，会触发冻结操作，但实际的内存回收可能需要一些时间。

  3. 临时峰值:

    • 在进行大批量数据修改时，可能会出现短暂的内存使用高峰，导致 ACTIVE_SPAN 超过 MEMSTORE_LIMIT。这种情况通常是暂时的，随着数据的稳定，内存使用量会逐渐下降。

查询和验证

为了进一步验证这个问题，您可以执行以下步骤：

  1. 检查内存使用趋势:

    • 使用 oceanbase.GV$OB_MEMSTORE 视图定期查询内存使用情况，观察 ACTIVE_SPAN 和 MEMSTORE_LIMIT 的变化趋势。
    obclient [oceanbase]> SELECT * FROM oceanbase.GV$OB_MEMSTORE WHERE tenant_id = 1002;

  2. 检查系统日志:

    • 查看系统日志，确认是否有内存相关的警告或错误信息。
    obclient> SELECT * FROM oceanbase.GV$OB_MEMORY WHERE tenant_id = 1002;

  3. 联系技术支持:

    • 如果问题持续存在且影响业务，建议联系 OceanBase 的技术支持人员进行进一步的诊断和处理。

结论

虽然 active_gb 超过 memstore_limit_gb 看起来不正常，但在某些情况下，这可能是由于统计延迟、内存回收机制或临时峰值导致的。建议您通过上述方法进一步验证，并在必要时联系技术支持人员。

详情请参考:

  1. 常见内存问题
  2. gv$tenant_memstore_allocator_info
  3. GV$OB_MEMSTORE
  4. GV$OB_MEMORY
  5. V$OB_MEMORY
  6. global_major_freeze_residual_memory
  7. V$OB_MEMSTORE
#5

收到，我先验证咨询下

1 个赞
#6

确实如此，内核视图中查到的就是 active > total ，可以参考小助手的解释

image
image743×354 82.3 KB