调优 SQL 时 OBClient 内存暴涨 100G 导致 OBServer 被 OOM Killer 的原因和解决方法

问题现象

OBServer 被操作系统 OMM killer，如下图所示。

机器内存上限为 377G，当时 OBServer 只占用 252G，理论上不会被 Killer，是有其他进程占用过多导致操作系统内存不足，操作系统杀死了占用最大的 OBServer 来释放内存。

排查 message 日志发现 OBClient 当时占用达到 114G，如下图所示。

如图中红框圈住的 30001191 为 RSS 的物理内存块，单位为 4kb，即：

• OBServer 占用 66120398*4/1024/1024= 252G（与 observer 内核日志打印相同）。

• OBClient 占用 30001191*4/1024/1024= 114G。

总占用达到 366G，超 97% 使用率，导致 OBServer 被操作系统 OMM killer。

查看 tsar 信息发现 OBClient 的内存占用在 15 分钟内暴涨 140G：

如上图所示可知： 11:18 分左右，系统内存从 263.4G 开始上涨。 11:36 分，OBServer 被操作系统 OOM Killer，OBServer 释放出 224G；但此时系统内存占用依然在上涨。 11:45 分，系统内存停止上涨，从 133G 到 178G。15 分钟涨了140G。 11:46 分，OBClient 进程正常退出，内存释放。

关键信息

OBServer 被操作系统 OOM Killer 但自身内存未超过 memory_limit_percentage，且从操作系统日志可看到 OBCliet 内存占用很高。

问题原因

当时有登陆此节点，使用 OBClient 连接集群后进行慢 SQL 调优。 该问题是由于在默认情况下，OBClient 查询结果集时，会将整个结果集缓存到内存中，然后输出。 这个问题场景下的 SQL，返回的结果集就占用了 140G，导致内存被打爆。 若使用 -q 参数，可以一行一行的获取结果集，而不是全部缓存到内存中，能规避这个问题。同时，需要注意的是，尽量不要在生产的 OBServer 节点上操作一些运维指令，防止影响到 OBServer 进程。

问题的风险及影响

OBServer 被操作系统 OOM Killer 杀死导致进程退出，若为 Leader 节点则可能发生无主选举影响业务。

影响租户

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

适用版本

OceanBase 数据库所有版本。

解决方法及规避方式

• 解决方法：

  使用 OBClient 登录命令时添加 -q 参数，可以一行一行的获取结果集，而不是全部缓存到内存中。

• 规避方式：

  尽量不要在生产的 OBServer 节点上操作一些运维指令，或者开启其他进程，防止影响到 OBServer 进程。