Oceanbase集群中，多台主机经常、间歇提示“ Cannot allocate memory”，文中通过分析、定位，解决问题，最后提出对oceanbase是否存在OOM的一些思考。

0.ENV

Centos7.6；

oceanbase 2.2.75,问题适用OceanBase所有版本。

1.问题现象

1) 运行现状

现有3台虚拟机(4C/16G)，每台上面运行1个observer（分配15G内存）和1个obproxy。

2)  操作系统经常间歇提示不能分配内存

运行约半天到一两天时间(时间间隔不等)，其中一台(随机出现)observer所在主机执行命令提示：

“-bash: fork: Cannot allocate memory”，此时几乎所有操作系统命令不能执行，reboot也不能执行。

3) 同时主机界面提示空间不足

2. 紧急解决方案

当前observer故障主机资源不足，几乎不能执行系统操作，该主机上observer异常，采用强制重启observer虚拟机后，observer恢复正常。

3. 问题分析及定位

1) 重启主机后查看系统配置

observer[1-3]:4C/16G，3台主机资源相同。

2) 重启后查看内存使用

当前内存使用正常，后续通过脚本实时监控3台observer异常时，运行内存是否消耗完。

3) 系统参数配置查看

查看资源配置文件：

确认进程数限制：

[root@ob2 ~]# sysctl kernel.pid_max
kernel.pid_max = 131072

当前为131072，非默认配置，进程数配置无异常，后续通过脚本实时监控3台observer异常时，运行进程是否达到进程限制。

4) 重启后磁盘空间确认

当前磁盘空间使用正常，/data/1使用率96%，和其它运行几台主机相同，其它目录也有剩余空间，后续通过脚本实时监控3台observer异常时，主机空间是否不足。

5) 查看observer资源配置

每个observer内存分配15G，observer系统租户保留5G。

6) 系统日志查看

报错时间节点，同时有空间不和不能分配内存报错，/run/systemd/users/0: No space left on device，后经近一步判断空间不足文件文件名会随机变化，如/run/systemd/users/UID，其中代表用户id,曾出现过root用户、admin(oceanbase管理用户)等其它系统用户均有报错。

7) 故障点observer.log日志查看

日志提示不能分配内存。

8) 实时监控脚本协作定位问题

通过实时监控脚本监控系统运行进程数、文件大小、系统空间、内存使用，在故障时间点便于近一步定位分析。

上图为故障时间点抓取的信息，发现available内存为400M左右，内存资源较为紧张，同时结合observer.log报错，定位问题为系统内存不足。

4. 问题原因

Observer主机内存16G，memory_limit参数设置observer使用15G，同时obproxy使用内存1-2G，。系统运行一段时间后，observer内存使用慢慢提高，而操作系统、observer、obproxy在有限的16G内存下，资源争抢，最终导致observer异常，系统内存不足而执行操作系统命令。

5. 解决方案

1) 解决方案

提供"一扩一减"两种方案解决：

方案一：

宿主机内存资源绰绰有余，可以关闭服务和虚拟机后，给3台虚拟机增加添加内存，由16G调整为20G；

方案二：

调整observer参数，将observer内存从15G降到12G,采用两种方式更改。

方案二详见《0089.O 调整oceanbase(memory_limit)参数的两种方法

》

https://mp.weixin.qq.com/s/X-lTmR2k2bGdM8DbK5prHw

2) 方案一操作过程

kill observer进程，关闭observer主机，将内存由16G增加到20G,然后启动主机，采用逐台操作的方法，一台重启完成，再操作另外一台。

kill observer进程：

# su - admin
$ kill -9 `pidof observer`

基于observer的架构，kill observer进程不会导致业务中断、数据丢失发生，但关闭正在提供服务的obproxy时，会有短暂业务中断。

3) 处理后观察数天

问题处理后，observer自9月3日重启以来，观察5天有余，再未发生以前不定期、频繁故障的问题。

6. OceanBase是否存在OOM的思考

首先，从未读过OceanBase源码，代码层面无从得知。

回到问题出现的时候，当时也在怀疑OceanBase是否存在很多软件通病--OOM问题？

后来划分20G内存后，其中observer使用15G，obproxy使用1-2G，系统保留约3G,如果存在OOM问题，在较少保留系统内存时，势必会再出现“Cannot allocate memory”问题，经过增加内存处理，数天的稳定运行，从侧面佐证了OceanBase不存在OOM问题。

个人认为ob的内存管理还是很不错的，通过租户级别对系统资源，包括CPU、内存、磁盘等资源有效的控制，实现了资源的隔离，也可动态进行调整，给个中立的技术观察赞。