最近oceanbase社区版经常出现内存不足导致ob服务退出 重启后能解决

【 使用环境 】生产环境 or 测试环境
生产环境
【 OB or 其他组件 】
系统centeros 7.9
ob版本 4.1.0.1
ocp用的是ocp-express版本的

服务器 A 192.168.1.20 ob 4.1 64核128G 1T SSD 主
服务器 B 192.168.1.21 ob 4.1 64核128G 1T SSD
服务器 C192.168.1.22 ob 4.1 64核128G 1T SSD
服务器 D 192.168.1.23 ob 4.1 64核128G 1.2T SSD
【 使用版本 】
【问题描述】清晰明确描述问题
最近几天都会出现节点掉线并且ob进程退出再次启动提示内存不足 希望大佬帮忙看看这是今天掉线起不来的节点日志
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
使用obdiag手机了日志,日志地址
https://patent-oss.oss-cn-shanghai.aliyuncs.com/ob_log_192.168.1.22_20240302174822_20240302181922.zip

1 个赞

128G 内存的机器 OB 应该能很好的运行。估计是内存参数哪里设置有问题。
可以先发一下下面 SQL看看资源情况。

select zone,concat(SVR_IP,':',SVR_PORT) observer,
	cpu_capacity_max cpu_total,cpu_assigned_max cpu_assigned,
	cpu_capacity-cpu_assigned_max as cpu_free,
	round(memory_limit/1024/1024/1024,2) as memory_total,
	round((memory_limit-mem_capacity)/1024/1024/1024,2) as system_memory,
	round(mem_assigned/1024/1024/1024,2) as mem_assigned,
	round((mem_capacity-mem_assigned)/1024/1024/1024,2) as memory_free,
	round(log_disk_capacity/1024/1024/1024,2) as log_disk_capacity,
	round(log_disk_assigned/1024/1024/1024,2) as log_disk_assigned,
	round((log_disk_capacity-log_disk_assigned)/1024/1024/1024,2) as log_disk_free,
	round((data_disk_capacity/1024/1024/1024),2) as data_disk,
	round((data_disk_in_use/1024/1024/1024),2) as data_disk_used,
	round((data_disk_capacity-data_disk_in_use)/1024/1024/1024,2) as data_disk_free
from gv$ob_servers;

select t1.name resource_pool_name, t2.`name` unit_config_name, 
	t2.max_cpu, t2.min_cpu, 
	round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
	round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops, 
	t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
	t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
	join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
	join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
	left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;

然后发一下每个机器的 内存使用情况

free -h
1 个赞

刚又蹦了 21服务器 https://patent-oss.oss-cn-shanghai.aliyuncs.com/log.tar.gz这是日志
这是第一个sql执行的结果


这是第二个sql执行的结果

这是free-h

20 21 22 依次出现oceanbaseSever进程自己掉 直接用obd cluster start obs -s 192.168.1.2x 去连接的话出现内存不足 只有重启这个服务器才能释放内存在去用obd cluster start obs -s 192.168.1.22可以连接上

20服务器又蹦了。。。


这是关于内存的配置

上面第二个 SQL 我之前发错了,重新发一下结果看看。

select t1.name resource_pool_name, t2.`name` unit_config_name, 
	t2.max_cpu, t2.min_cpu, 
	round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
	round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops, 
	t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
	t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
	join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
	join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
	left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;

20 机器的 free -h 看起来问题很大 ,free 和 available 内存都很小,可能是 OOM 了。
看看 20 机器的 /var/log/messages 里是否有 oom-killer 字眼。

cat /var/log/messages|grep  oom-killer

20 机器上是否还跑了别的占用内存的程序?

将 20 机器上的 observer kill 掉后再看看 free -h

kill -9 `pidof observer`
sleep 5
free -h
top 


sql执行结果

这个20上只有跑ob其他业务没跑都是单独的

[root@obs1 ~]# cat /proc/meminfo
MemTotal: 197910840 kB
MemFree: 101134296 kB
MemAvailable: 107016272 kB
Buffers: 266760 kB
Cached: 6077332 kB
SwapCached: 3572 kB
Active: 17549040 kB
Inactive: 3933936 kB
Active(anon): 15108576 kB
Inactive(anon): 39740 kB
Active(file): 2440464 kB
Inactive(file): 3894196 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 4194300 kB
SwapFree: 4188924 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 15135844 kB
Mapped: 82496 kB
Shmem: 9372 kB
Slab: 366752 kB
SReclaimable: 232224 kB
SUnreclaim: 134528 kB
KernelStack: 18528 kB
PageTables: 37652 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 66767000 kB
Committed_AS: 19563348 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 571968 kB
VmallocChunk: 34208090108 kB
Percpu: 11264 kB
HardwareCorrupted: 0 kB
AnonHugePages: 13647872 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 35530
HugePages_Free: 210
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 198528 kB
DirectMap2M: 8189952 kB
DirectMap1G: 195035136 kB
kill掉之后还是没有释放内存

当前其他节点的内存情况

服务器内存用了大页,先关闭掉。

HugePages_Total: 35530
HugePages_Free: 210
HugePages_Rsvd: 0
HugePages_Surp: 0

这个如何关闭

修改 /etc/sysctl.conf ,搜索 vm.nr_hugepages ,设置为 0.

vim /etc/sysctl.conf
vm.nr_hugepages=0

重启服务器,先不要启动 OB 。

free -h

cat /proc/meminfo |grep Huge

然后再启动 OB 。