队列爆自动 obstack 功能可能导致 OBServer 暂时 hang 住

问题现象

1. OBServer 进程短时间 hang 死，现象类似 gcore/gdb attach，之后自行恢复。

2. 前置问题为队列爆，hang 的时间长度与进程内存大小相关，目前不清楚是否为线性关系，观察到 600G 的进程大约卡住 10s。

3. 该问题仅存在 OceanBase 数据库 V4.2 及之后所有版本，此前版本不存在此问题。

关键诊断信息

触发条件

租户队列爆。

事后诊断

1. OBServer 进程 hang 期间 observer.log 日志中断，CPU 和网卡带宽会跌至很低，如执行 tsar --cpu 命令。

   

2. 恢复后会有其他模块响应日志超时，打印日志信息。

   [2024-01-31 19:29:22.732486] EDIAG [RPC.FRAME] batch_rpc_easy_timer_cb (ob_net_easy.cpp:641) [4940][BatchIO][T0][Y0-0000000000000000-0-0] [lt=9][errcode=0] LOGGER COST TOO MUCH TIME, cost: 9062019, time dist: FORMAT_END=9041611, ALLOC_END=20407, APPEND_END=0, BACKTRACE: 0x7861450 0x79187df 0x7a763e9 0x7a761c4 0x7947071 0x78da6cb 0x17ac5e2d 0x78611e5 0x1982ba15 0x78f31b9 0x198390dc 0x172524aa 0x1724e895 0x7fa0a4e08e25 0x7fa0a4b32bad
   

   功能触发时也会有 faststack 日志，但是只有触发时 ret=0，如下图所示。

   

3. 不管是否有无 obstack 结果文件产生，都存在这个问题。

问题原因

租户队列爆场景保留 obstack 是 OceanBase 数据库 V4.x 版本新增的诊断功能（用于内核自动保留队列爆时的堆栈辅助研发诊断），该功能依赖 obstack。该功能默认开启，但有半小时的最小触发间隔（也可以通过这个工具调整），因此不会过于频繁的 hang 住，也可以基于这个特性来判断是否确实是该问题，即如果队列长时间爆，是否有固定半小时一次的进程卡住；问题的根因是由于该功能依赖于 obstack，因此实现上需要通过创建子进程来调用 obstack 抓去 OBServer 堆栈。Linux 下的 clone 调用会导致父进程 hang 住直到成功，clone 实际耗时与进程内存大小相关（观察到），因此在大内存场景（几百 GB）会较为明显。

问题的风险及影响

可能导致该 server 上的业务流量短时间跌 0，以及其他涉及该 server 的请求卡住。因此该问题的实质是故障的租户影响了租户所在 server 的所有租户的请求。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版本 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP5（oceanbase-4.2.1.5-105000072024041817）、V4.2.3（oceanbase-4.2.3.0-100000052024041220）。

• 无需特殊处理，会自行恢复，确定问题后规避即可，但该问题的前置问题租户队列爆一般需要重启恢复。强烈建议查清队列爆的原因。

规避方式

以下满足其一即可。

1. 避免租户队列爆。

2. 通过其他方式降低进程内存水位以降低卡住时间，如 memory_chunk_cache_size。

3. 彻底关闭自动保留堆栈功能（推荐），不需要重启。

   # OBServer 的安装目录
   cd /home/admin/oceanbase
   # 创建目录
   mkdir tools;
   # 不要 chmod +x，不能有 x 权限
   touch tools/callstack.sh