问题背景

部署 OCP 集群时，机器资源如果不到位，OCP 部署经常会在元数据库 OB 集群初始化（bootstrap）这一步失败，或者在 OCP 元数据库创建（ocp_meta、ocp_monitor）这一步失败。
不过精确调整容器内存和集群内部各个内存参数后，还是可以部署成功的。详情见文末参考。

但是，在后面使用 OCP 上传 OB 的软件包的时候，还是有可能会再次失败。

这里探索一下 OCP 里软件上传过程的原理并分析其性能，这个跟 OB 用户导入数据时报内存错误情形基本相同。

问题分析

1. OCP 上传OB 软件包。

OB 软件包的大小大概 有 642MB 左右。

root@MQBOOK: # ls -lrth oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm
-rwxrwxrwx 1 root root 642M Apr  4 10:02 oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm

上传页面：

image1723×391 55.3 KB

上传软件过程中主要是 OCP 服务端接收文件，写入到 OCP 容器的本地目录。这个过程 OCP JAVA的可用内存资源很重要，如果太小，写的过程中可能会出现 OOM 。当然如果使用了流式读取技术，也可以做到对内存消耗太大。这里不确认。

docker exec -it ocp bash

[root@server064 admin]# find . |grep oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm
./data/files/sys-package/oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm

如果是上传过程中报错，那需要到这个位置清理一下这个文件，后面再次上传才不会报错。

2. 文件上传后解析入库。

OCP 读取上传的 RPM 包再写入到 OCP 元数据库也就是 OB 集群中，预计写入的量跟 RPM 包大小差不多，在 642MB 左右。

实际会写入到 OCP 元数据库下面表中。

select id, name, extension,round(total_size/1024/1024) total_size_mb ,status,create_time,update_time from storage_object_meta where name like 'oceanbase-3.2%';

select file_id, count(`index`),sum(`size`)/1024/1024 size_mb   from storage_object_block where file_id in (1000005)

3. 文件写入OB元数据库监控

OB 租户短时间内写入 640MB 内容，如果租户内存过小或者 IO能力太差，那么 OB 租户在转储的时候释放内存可能赶不上写入消耗内存的速度，在普通的 SAS 盘上这一步大概率也是会失败的。如果租户内存能在 2GB 以上以及用上 SSD 盘，那成功的概率还是很大的。

解决办法

下面是两种租户资源下的 OB 软件包上传时 OB 性能监控。

image1649×523 88.8 KB

第一次上传的时候，租户内存只有 2GB，memtable 能用的内存是 2GB*80%(memstore_limit_percentage 设置为80%）。此时 IOPS 非常高。如果是普通 SAS 盘，这里大概率会报错。
第二次时调大了租户内存资源到 6G，后面基本就没有 IOPS。

ALTER resource unit ocp_monitor_unit max_memory '1G', min_memory '1G' ;
ALTER resource unit ocp_unit max_memory '6G', min_memory '6G' ;

查看租户资源分布。这个基本是将OB 可用资源都分配尽了。

select t1.name resource_pool_name,  t2.`name` unit_config_name, t2.max_cpu, t2.min_cpu
, round(t2.max_memory/1024/1024/1024) max_mem_gb, round(t2.min_memory/1024/1024/1024) min_mem_gb
, round(t2.max_disk_size/1024/1024/1024) max_disk_size , 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
;

下图是第二次上传 RPM 包期间的 dooba 的监控图。

image1605×955 210 KB

脚本位置 OB的安装目录 /home/admin/oceanbase/bin/dooba

框住的部分就是租户 ocp_meta 的 memtable 内存变化情况。

更多阅读参考

• OB 内存分配概述 OB 3.2 在内存使用方面跟 2.2 变化不是很大，这个分析还适用。

• 如何在小内存服务器上玩转 OB 企业版部署

老哥6666

已加入官方精选~