如何通过修改配置或是源码减少OB3.10的整体资源消耗

OceanBase 技术问题
,
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】3.10
【问题描述】
obd配置文件，参考最小配置
memory_limit: 4G
system_memory: 2G
datafile_size: 1G
log_disk_size: 1G
cpu_count: 16

observer记录ObPGPartition::init函数执行次数2400次，研究日志可知，多个线程初始化不同的partition信息引发。

想请问一下有什么办法可以减少线程数量和partition数量，以达到控制这个函数执行次数最小。方法不限于修改配置文件或是修改ob源码或是obd源码

背景：使用动态插桩工具拉起ob数据库失败，原因是资源消耗过大。动态插桩工具用于检测x86服务器和arm服务器上内存相关数据检测。
正常情况：
[STORAGE] ob_pg_partition.cpp:128 [1232458][0][Y0-0000000000000000] [lt=5] [dc=0] ObPGPartition::init(ret=0, pkey={tid:1924145348722, partition_id:13, part_cnt:0}, this=0xffff00473f40)

动态插桩拉起场景
[STORAGE] ob_pg_partition.cpp:128 [2950796][0][Y0-0000000000000000] [lt=68526] [dc=0] ObPGPartition::init(ret=0, pkey={tid:1099511627988, partition_id:11, part_cnt:0}, this=0xffdf38c30ec0)

可见lt记录时长很大
【复现路径】问题出现前后相关操作
参考obd最小配置文件拉起ob数据库
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
无外发权限，请见描述

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根据文档库中的信息，您可以采取以下措施减少 OceanBase 3.10 的整体资源消耗，特别是针对线程数量和分区（partition）数量的控制。这些建议包括配置调整和潜在的源码修改方向。

配置调整

1. 减少租户资源规格

通过调整租户的资源配置来降低 CPU 和内存使用量。可以适当减少 MAX_CPU 和 MEMORY_SIZE 的值，以限制每个租户可使用的最大资源量。例如：

ALTER RESOURCE UNIT test_unit MIN_CPU = 1, MAX_CPU = 1, MEMORY_SIZE = '2G';

参考自：创建资源单元

2. 调整日志盘大小

将 LOG_DISK_SIZE 设置为更小的值，如 1G 或者根据实际需求调整。注意，此参数默认是内存规格值的三倍，因此在减小内存的同时也会影响日志盘大小。

ALTER RESOURCE UNIT test_unit LOG_DISK_SIZE = '1G';

3. 控制活跃线程数

OceanBase 主要依靠控制活跃线程数量来管理 CPU 使用率。可以通过设置租户资源池时指定较低的 CPU 规格来间接限制线程数。此外，确保操作系统级别的 cgroup 配置正确，以便更好地对 CPU 进行隔离和限制。
参考自：CPU 消耗控制

源码修改建议

对于您提到的 ObPGPartition::init 函数执行次数过多的问题，考虑到这是由于多个线程初始化不同的分区信息所引起的，可以从以下几个方面考虑优化：

1. 分区策略调整

评估当前数据库表的分区策略是否合理，尝试合并或减少分区的数量。合理的分区设计不仅可以提高查询性能，还能减少不必要的分区初始化操作。

2. 线程池优化

如果可能的话，检查并优化 OceanBase 内部的线程池实现，避免在同一时间点上有过多线程同时进行分区初始化工作。这可能涉及到对 OceanBase 源代码中与线程调度相关的部分进行分析和改进。

3. 延迟初始化

研究是否有办法延迟某些非关键分区的初始化过程，直到它们真正被访问时才进行初始化，从而分散初始化压力。

动态插桩工具适配

鉴于动态插桩工具导致了额外的资源开销，建议与该工具的开发者沟通，探讨是否存在优化其运行模式的可能性，比如减少对特定函数调用的监控频率或者优化插桩代码本身以降低对目标程序的影响。

综上所述，以上方案结合了配置调整和潜在的源码层面优化，旨在帮助您有效降低 OceanBase 在测试环境下的资源消耗，并解决因动态插桩工具引入的问题。如果您需要进一步的技术支持，请联系 OceanBase 官方团队获取更多帮助。

具体信息可参考以下文档:

  1. ALTER RESOURCE UNIT
  2. 租户间的资源隔离
  3. 在您开始前
  4. （可选）配置 limits.conf
  5. 多租户线程常见问题
  6. 产品 FAQ
  7. obshell-sdk-go 快速上手
  8. 使用命令行部署 OceanBase 数据库生产环境
  9. 集群级别的扩容和缩容
  10. 内存管理概述
#5

3.1版本太低了，目前已不进行维护，建议升级更换到4.x最新版
最小规格限制为：
memory_limit: 6G
system_memory: 1G

#6

4.0能够通过配置文件修改线程数量和partition数量吗？

#7

根据文档库中的信息，在 OceanBase V4.x 版本中，线程资源的配置方式发生了变化，并且不再支持通过具体的任务类型来直接配置线程资源。这意味着您不能像以前那样通过简单的配置文件选项来精确控制每个任务类型的线程数量。不过，仍然可以通过一些间接的方法和特定配置项来影响线程的行为以及分区的数量。

间接控制线程数量

1. 使用租户级配置项

在 V4.x 版本中，可以使用以下租户级别的配置项来设置不同优先级的工作线程占用 CPU 时间片的权重，从而间接影响线程调度：

  • ha_high_thread_score：用于控制复制、Rebuild 和恢复等高可用高优先级线程的工作线程数。
  • ha_mid_thread_score：用于设置迁移任务等高可用中优先级线程的工作线程数。
  • compaction_low_thread_score：用于设置低优先级 Compaction 的工作线程占用 CPU 时间片的权重。

这些配置项的具体说明可以在相应的文档中找到（例如 ha_high_thread_score）。通过调整这些参数，您可以优化系统性能并减少不必要的线程竞争。

2. 控制并发度相关配置

此外，还有一些配置项可以直接限制某些操作的最大并发度，进而减少线程的创建：

  • data_copy_concurrency：用于设置系统中并发执行的数据迁移复制任务的最大并发数，默认值为 20。
  • server_data_copy_in_concurrency 和 server_data_copy_out_concurrency：分别用于设置单个节点迁入和迁出数据的最大并发数，默认值均为 2。
  • migrate_concurrency：用于设置内部数据迁移的最大并发数，默认值为 10。
  • restore_concurrency：用于设置从备份恢复租户数据时的最大并发度，默认值为 0。
  • fast_recovery_concurrency：用于控制 RootService 调度的快速恢复任务在 OBServer 上执行的并发数，默认值为 10。
  • minor_merge_concurrency：用于设置转储时的并发线程数，默认值为 min[10, cpu_cnt]。

以上配置项均不需要重启 OBServer 即可生效，具体描述请参见相关文档片段。

控制 Partition 数量

对于分区数量的控制，主要取决于您的数据库设计和表结构定义。OceanBase 社区版并没有提供直接通过配置文件来全局减少所有表分区数量的功能。但是，您可以采取以下措施来管理和优化分区：

  • 评估现有分区策略：检查当前数据库表的分区策略是否合理，尝试合并或减少不必要的分区。合理的分区设计不仅可以提高查询性能，还能减少初始化过程中涉及的分区数目。

  • 调整表定义：如果可能的话，修改表定义以减少分区数量。例如，将范围分区改为哈希分区，或者增加分区键的数量以更均匀地分布数据。

  • 使用默认分区：对于不需要特别分区处理的表，可以考虑不进行显式分区，让 OceanBase 自动管理。

综上所述，在 OceanBase V4.x 中虽然无法直接通过配置文件修改线程数量，但可以通过上述提到的租户级配置项和并发度限制来间接达到目的。至于分区数量，则需要从数据库设计层面入手进行优化。

如果您希望进一步定制化或深入理解如何更好地配置和优化 OceanBase，请参考官方文档或联系 OceanBase 技术支持团队获取更多帮助。

具体信息可参考以下文档:

  1. merge_thread_count
  2. data_copy_concurrency
  3. server_data_copy_in_concurrency
  4. migrate_concurrency
  5. server_data_copy_out_concurrency
  6. restore_concurrency
  7. fast_recovery_concurrency
  8. enable_pg
  9. minor_merge_concurrency
  10. election_cpu_quota

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#8

线程数量这是业务发送过来的吧？

连接数通过变量来设置 SHOW VARIABLES LIKE ‘max_connections’;
分区数可以限制 参数max_partition_num