问题背景
部署 OCP 集群时，机器资源如果不到位，OCP 部署经常会在元数据库 OB 集群初始化（bootstrap）这一步失败，或者在 OCP 元数据库创建（ocp_meta、ocp_monitor）这一步失败。
不过精确调整容器内存和集群内部各个内存参数后，还是可以部署成功的。详情见文末参考。
但是，在后面使用 OCP 上传 OB 的软件包的时候，还是有可能会再次失败。
这里探索一下 OCP 里软件上传过程的原理并分析其性能，这个跟 OB 用户导入数据时报内存错误情形基本相同。
问题分析
- 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
上传页面：
上传软件过程中主要是 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
如果是上传过程中报错，那需要到这个位置清理一下这个文件，后面再次上传才不会报错。
- 文件上传后解析入库。
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%';
| id | name | extension | total_size_mb | status | create_time | update_time |
|---|---|---|---|---|---|---|
| 1,000,005 | oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm | rpm | 642 | FINISHED | 2023-06-06 16:15:33.000 | 2023-06-06 16:16:06.000 |
| 1,000,006 | oceanbase-3.2.4.1-101000052023010822.el7.x86_64.rpm.oceanbase_upgrade_dep.yml | yml | 0 | FINISHED | 2023-06-06 16:17:33.000 | 2023-06-06 16:17:33.000 |
select file_id, count(`index`),sum(`size`)/1024/1024 size_mb from storage_object_block where file_id in (1000005)
| file_id | count(index) |
size_mb |
|---|---|---|
| 1,000,005 | 642 | 641.61681747 |
- 文件写入OB元数据库监控
OB 租户短时间内写入 640MB 内容，如果租户内存过小或者 IO能力太差，那么 OB 租户在转储的时候释放内存可能赶不上写入消耗内存的速度，在普通的 SAS 盘上这一步大概率也是会失败的。如果租户内存能在 2GB 以上以及用上 SSD 盘，那成功的概率还是很大的。
解决办法
下面是两种租户资源下的 OB 软件包上传时 OB 性能监控。
第一次上传的时候，租户内存只有 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
;
| resource_pool_name | unit_config_name | max_cpu | min_cpu | max_mem_gb | min_mem_gb | max_disk_size | tenant_name |
|---|---|---|---|---|---|---|---|
| sys_pool | sys_unit_config | 5 | 5 | 3 | 3 | 93 | sys |
| ocp_resource_pool | ocp_unit | 4 | 4 | 6 | 6 | 100 | ocp_meta |
| ocp_monitor_pool | ocp_monitor_unit | 4 | 4 | 1 | 1 | 100 | ocp_monitor |
下图是第二次上传 RPM 包期间的 dooba 的监控图。
脚本位置 OB的安装目录 /home/admin/oceanbase/bin/dooba
框住的部分就是租户 ocp_meta 的 memtable 内存变化情况。
更多阅读参考
-
OB 内存分配概述 OB 3.2 在内存使用方面跟 2.2 变化不是很大，这个分析还适用。