【 使用环境 】测试环境
【 OB 】OceanBase 数据库4.2.1.7
【问题描述】数据库cpu非常大，使用sql
select request_id,usec_to_time(request_time),ELAPSED_TIME,QUEUE_TIME,EXECUTE_TIME,query_sql from v$OB_SQL_AUDIT where ELAPSED_TIME > 2000000;
查询慢查询时发现，除了自己服务的sql还有许多的ob数据库自己运行的sql。这个为什么
现在把测试的服务全部关掉后，数据库cpu还是没有降下来
【附件及日志】
用诊断工具obdiag拿一下CPU高需要的信息，方便高效的定位问题。
obdiag gather scene run --scene=observer.cpu_high
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768259
gv$ob_sql_audit 字段很多，把这些sql 的 client_ip、 user_client_ip、user_name 都列出来看看 sql 是发自 ob 内部的还是 ocp 的。
此外，还有一个可能是不是这个集群的合并不正常了，检查一下这个先。
没有部署ocp，只有单个数据库
1、按照楼上说的 使用obdiag收集一下信息 可以看看具体的问题
current_clocksource_192_168_80_1_result.txt (83 字节)
obstack2_192.168.80.1_20250102225234.zip (15.4 KB)
perf_192.168.80.1_20250102225238.zip (147.1 KB)
result_summary.txt (2.1 KB)
sql_result.txt (495.3 KB)
命令提取的日志
election.7z (5.8 MB)
observer.7z (2.8 MB)
rootservice.7z (3.8 MB)
observer.log20250102222933794.7z (8.8 MB)
[observer.log.wf.7z|attachm
observer.log20250102225224324.7z (9.4 MB)
ent](upload://3waKZ5la3z5UGGpQ1SvAF8UAgUE.7z) (139.3 KB)
的确有点大
不重启执行不了obdiag相关的命令会卡住，所以重启了一次数据库。重启后数据库的cpu恢复正常了，后面执行obdiag gather scene run --scene=observer.cpu_high命令，提取的top数据是重启后的
重启了之后拿到的observer.cpu_high数据其实价值就不大了。不过从拿到的结果来看，排除时钟源类型导致cpu高的问题了。
你再拿一份巡检报告回来，obdiag check
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768218
从发回来的巡检结果来看，没有特别严重已知的问题。
再说回来cpu高问题，还是需要抓“现行”，现在你的环境重启了，查询起来是不是快了，你让集群运行一段时间，当CPU开始显著升高的时候，你再抓一个
obdiag gather scene run --scene=observer.cpu_high
好，
后期可以在观察观察 如果有问题 可以先用obdiag收集信息 平时也可以用obdiag巡检
obdiag gather scene run --scene=observer.cpu_high
我们生产上CPU高天天报警，另外集群其他两个机器就没有事，一直没时间去查，ocp中建议是优化sql。但是明显不是什么sql都需要去创建sql，有时候需要优化逻辑，不知道是不是和产品，避免跨级事务，搞的同一机器上，才导致的高。
4.2 版本以后的 OCP 里租户的 CPU 利用率的计算逻辑看起来是 实际CPU 时间/ 租户最大 CPU 配额，现在这个值基本上很准了。
4.0 版本以及以后的 OB 集群在部署后默认还开启了 cgroup CPU 资源隔离（集群参数 enable_cgroup 为 true ）。
以上两点加起来现在 OCP 里租户的 CPU 资源利用率就非常精准且不会超过 100% 。即使你开启了“超卖”，在这个统计逻辑下，这个值依然不会超过 100% 。
所以，这里你的问题是 CPU 告警。告警了，那是真的说明租户需要更多的 CPU 资源。应对方案首先是优化 SQL，降低一些 SQL 的 CPU 、IO 消耗。通常就是通过索引调优，其次就是 outline 调整 sql执行i计划。其他还有一些手段如收集统计信息等，也是间接改变不好的执行计划。
租户开启了分布式（指租户 primary_zone 设置为多个 zone），很可能导致业务事务在内部是分布式事务，事务的平均延时会增加。不过跟租户在单节点的CPU利用率增加没有必然的关系。但是分布式会让你的优化变得复杂。就优化sql而言，可以先设置 primary_zone设置为 单 zone ，让某些明显的 SQL 问题暴露，先优化。如果已经无从优化，租户改为 分布式，压力能分摊到多个节点（分摊水平不一定相同是正常的）。如果节点此时 CPU 利用率还是很高经常告警，那就给租户 CPU 扩容。
此外，由于开启了 cgroup CPU 资源隔离，如果租户的CPU 配额不高，是容易出现机器很空闲但是租户CPU利用率高的情况。这种情形你也可以考虑关闭 cgroup CPU 资源隔离，让这个租户多用一些 CPU 。此时你会观察到 OCP 的租户 CPU 利用率超过 100%。这样节点的CPU 利用率会更高一些。资源隔离有利有弊。
资源分的那么清楚就会避免浪费；不分那么清楚，有时候又会觉得有些租户占了其他租户的便宜。如果是线下的OB 业务，都是自己的业务，如果不同租户业务负载特点不一样，或者说互补，不隔离是最好的。当然隔离开启超卖也是一个做法。
如果你就一个租户，那先开启分布式用法，还不行就扩容租户 CPU 。
详细的可以看： 闲话 OB 多租户资源隔离技术
