社区版docker部署 CPU一直在50%左右持续

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.5LTS
【问题描述】使用docker部署的，空闲状态下cpu一直在50%左右，是什么原因呢？
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

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

image
image973×22 1.38 KB

image
image860×222 3.82 KB

3 个赞
#3

推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。

日志采集场景: CPU高
日志采集命令: obdiag gather scene run --scene=observer.cpu_high

为了更好地帮助您分析问题，请您按照上述命令采集日志并上传给我们。此外，还需要请您提供以下信息：

  1. OceanBase 数据库的具体版本号是多少？
  2. Docker 部署时使用的资源配置（如 CPU 核心数、内存大小等）是什么？
  3. 是否有运行任何后台任务或定时任务？如果有，请描述这些任务的性质和频率。
  4. 除了 CPU 占用率较高外，是否还观察到其他异常现象（如内存占用、磁盘 I/O 等）？
  5. 是否对 OceanBase 进行了任何特定的参数调整？如果有，请列出相关参数及其值。

附上敏捷诊断工具 obdiag 使用帮助链接

2 个赞
#4

image
这一列是CPU

1 个赞
#5

CPU高的进程
image

1 个赞
#6

根据您提供的信息，Docker 部署的 OceanBase 社区版在空闲状态下 CPU 占用率持续在 50% 左右。以下是可能的原因及解决方法：

可能原因分析

  1. 选举线程占用 CPU

    • 在 OceanBase 数据库中，选举线程会定期进行心跳检测和状态同步，即使在空闲状态下也会消耗一定的 CPU 资源。
    • 根据文档片段《5900.election_cpu_quota.md》，选举线程的 CPU 配额可能会导致较高的 CPU 使用率。

  2. sync_io_thread_count 参数配置

    • 根据文档片段《sync_io_thread_count → 使用说明》，sync_io_thread_count 参数会影响 IO 线程的数量。如果该参数配置不当，可能会导致过多的线程竞争 CPU 资源。
    • 当 CPU 核数小于或等于 16 时，线程数 = CPU 核数 * 6；当 CPU 核数大于 16 时，线程数 = 16 * 6 +（CPU 核数 - 16）* 2。

  3. 后台任务或定时任务

    • 如果有运行任何后台任务或定时任务，这些任务可能会占用较多的 CPU 资源。

  4. 系统监控工具的影响

    • 您提到使用了 top 命令查看 CPU 使用情况，某些系统监控工具本身可能会占用一定的 CPU 资源。

解决方法

  1. 检查选举线程的 CPU 配额

    • 登录到 OceanBase 数据库，执行以下 SQL 查询选举线程的 CPU 配额：
      SHOW PARAMETERS LIKE 'election_cpu_quota';
    • 如果选举线程的 CPU 配额过高，可以尝试调整该参数值。例如，将其设置为较低的值：
      ALTER SYSTEM SET election_cpu_quota=10;

  2. 调整 sync_io_thread_count 参数

    • 检查当前 sync_io_thread_count 参数的值：
      SHOW PARAMETERS LIKE 'sync_io_thread_count';
    • 根据实际的 CPU 核数调整该参数值。例如，如果 CPU 核数为 8，则可以将该参数设置为 48（8 * 6）：
      ALTER SYSTEM SET sync_io_thread_count=48;

  3. 排查后台任务或定时任务

    • 检查是否有运行任何后台任务或定时任务，并评估其对 CPU 的影响。如果有不必要的任务，建议停止或优化这些任务。

  4. 减少系统监控工具的影响

    • 尽量减少使用 top 等系统监控工具的频率，或者考虑使用更高效的监控工具，如 htop 或 glances。

进一步诊断

如果以上方法未能解决问题，建议使用 OceanBase 的敏捷诊断工具 obdiag 收集更多诊断信息：

obdiag gather scene run --scene=observer.cpu_high

将采集到的日志提供给我们以便进一步确认问题所在。此外，还需要请您提供以下信息：

  • OceanBase 数据库的具体版本号。
  • Docker 部署时使用的资源配置（如 CPU 核心数、内存大小等）。
  • 是否有运行任何后台任务或定时任务？如果有，请描述这些任务的性质和频率。
  • 除了 CPU 占用率较高外，是否还观察到其他异常现象（如内存占用、磁盘 I/O 等）。
  • 是否对 OceanBase 进行了任何特定的参数调整？如果有，请列出相关参数及其值。

希望以上信息能够帮助您解决问题！

详情请参考:

  1. CPU 工具
  2. DBA_OB_AUX_STATISTICS
  3. ODP 性能分析
  4. 检查主机信息
  5. 集群总览
  6. sync_io_thread_count
  7. CDB_OB_AUX_STATISTICS
  8. 19900.server_cpu_quota_max.md
  9. 5900.election_cpu_quota.md

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

2 个赞
#7

看看sync_io_thread_count参数是不是配置不对

#8

我也看看我的是不是选举cpu高，我好像没改这参数，默认值，CPU也不低

#9
  1. 系统参数设置不合理（线程数太高）

OceanBase 默认会根据机器 CPU 数自动起大量线程：

调度线程（sys_task_queue_thread_num）

容灾线程

I/O 提交线程等

即使没有业务请求，这些线程仍会运行调度循环。

尤其在 Docker 中（特别是默认 cgroup 限制失效时），OceanBase 可能认为自己拥有所有 CPU 核心，从而分配了大量线程。

  1. 日志刷盘 / flush 日志线程频繁运行

    日志刷盘线程会定期检查是否有日志需要写入磁盘

    尽管无业务写入，但后台日志线程仍在 tick loop 中不断运行

  2. 系统监控线程和租户心跳机制活跃

OceanBase 自带大量的后台服务线程，如：

租户统计

负载采集

内存监控

异步任务轮询器

这些线程虽然不重，但线程数很多，加在一起可能形成一定负载
4. Docker容器资源虚拟化导致监控异常

在 Docker 中运行 OB 时，如果未正确设置：

--cpuset-cpus 或 --cpu-quota 等限制

OB 可能认为其拥有整个物理机资源，导致调度线程过多
#10

docker分配了cpu多少

#11

部署个obdiag可以采集相关问题信息

CPU高

obdiag gather scene run --scene=observer.cpu_high