OB单机版在备份后CPU一直居高不下，这两个线程是干什么的？【OB4.3.5】【obd工具】【CPU飙高】【备份】

【 使用环境 】 测试环境
【 OB or 其他组件 】OBD、备份
【 使用版本 】5.7.25-OceanBase-v4.3.5.3 ；obd --version 为 OceanBase Deploy: 3.4.0
【问题描述】使用obd安装集群并创建租户后，进行一次备份恢复成功，再进行一次备份恢复后报错无可用CPU，查看top发现observer占了3个CPU
【复现路径】使用obd安装集群并创建租户后，进行一次备份恢复成功，再进行一次备份恢复后报错无可用CPU

image1316×208 12.4 KB

查看top发现observer占了3个CPU，top -p pid -H查看是T1042_TimerWK2和T1040_TimerWK0主要占用

0429e6bab7236dec72ac991a5a714cb6990×280 15.2 KB

根据您的描述，OceanBase在使用obd工具进行备份恢复后遇到CPU占用率异常高，并且在第二次尝试备份恢复时失败并提示无可用CPU资源的问题。这可能是由于备份恢复过程中消耗了过多的CPU资源导致的。为了更好地诊断这个问题，我们推荐您使用obdiag工具来收集相关日志和执行根因分析。

推荐操作

根因分析场景: CPU高

根因分析命令: obdiag rca run --scene=observer.cpu_high

• 该命令将帮助识别可能引起CPU使用率高的原因。

日志采集场景: 合并问题、CPU高

日志采集命令:

• obdiag gather scene run --scene=observer.compaction
• obdiag gather scene run --scene=observer.cpu_high
• 这些命令将分别收集与合并操作和CPU高相关的日志信息。

请运行上述命令，并将得到的日志文件打包后提供给我们，以便进一步分析问题所在。

需要额外提供的信息

为了更精确地定位问题，请您回答以下问题：

1. 在执行备份恢复之前，系统是否已经处于较高的CPU负载状态？如果可以，请提供执行备份恢复前后的系统监控数据。
2. 备份恢复过程中是否有其他大型操作（如大规模数据导入/导出）同时进行？
3. 能否分享有关T1042_TimerWK2和T1040_TimerWK0线程的具体职责或文档链接？这有助于理解为什么这些特定线程的CPU使用率会变得非常高。
4. 您使用的OceanBase版本是多少？以及备份恢复期间涉及的数据量大约有多少？

期待您的回复及提供的日志文件，我们将尽快协助解决此问题。

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

cpu使用的进程配置的太大？

你好，你提的这个技术问题牵涉到OceanBase企业版范围内的功能细节；针对此类问题，建议你通过以下方式寻求帮助：

1. 如你所在的企业客户已签署OceanBase企业版销售合同，请你联系客户经理；

2. 如你所在的企业客户尚未签署OceanBase企业版销售合同，你可通过OceanBase官网商务咨询页面留下你的联系方式，OceanBase企业版的业务顾问会在一个工作日内与你联系。

另外，我们欢迎你使用社区版，并在论坛/社群中分享你对社区版本的想法、经验和问题，与其他社区成员共同交流。