数据库在一个时间里面变的非常慢，cpu占用特别高，想要排查一下

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】 OceanBase数据库4.0.0
【附件及日志】
obdiag analyze log分析结果
result_details.txt (413.2 KB)
election.7z (6.9 MB)
rootservice.7z (7.7 MB)
因为cpu占用高使用了obdiag gather scene run --scene=observer.cpu_high分析了一下
cpu.7z (578.2 KB)
麻烦排查一下

#3

如果是sql原因是否可以排查出来是那些sql

#4

是单节点部署的吗？机器和租户分别是什么配置啊，我看版本是4.0.0的，建议用4.2.x的版本测试

#5

对的，
配置文件.txt (2.0 KB)
用的主租户

#6

1、可以看下机器在慢的时间段里的负载情况
2、如果有ocp的话，看下‘租户sql诊断’

#7

抱歉，没有部署ocp，在慢的时间里面使用top 查看ob数据库cpu占用300，内存占用10多个g的样子

#8

还有大佬回复这个问题嘛

#9

image
image1190×1751 511 KB

解析了一下你发回来的perf火焰图，看起来是有跑批的SQL占用了大量的cpu，是不是你们业务SQL中有多表关联的跑批任务，火焰图中能看到nestloopjoin这个算子耗费较多cpu

#10

这块分析传过来的日志，看到是有很多表关联的查询，具体sql可以在cpu高的时候，通过GV$OB_PROCESSLIST，或者GV$OB_SQL_AUDIT查看有哪些复杂的sql在执行；
另外这里最好建议用ocp做下监控，可以很直观的通过topsql看到那些sql在跑

#11

另外通过分析你发回来的perf文件中的调用图可以看到确实是有查询的任务占用了cpu多

image
image1920×944 123 KB

结合这几点基本上可以看出来是有多表关联的查询语句的问题，你看看业务SQL

#12

4.0.0 版本太老了, 推荐使用4.2.1-bp6 最新的稳定版本, 做一下升级吧

#13

是的

#14

这个环境天天都有在运行的，慢查询的sql应该是一直都有在跑的，为什么会过这么久才会发生一次性能变差。

#15

性能突然变差原因比较多，SQL资源消耗增大是一个常见因素，比如SQL执行计划突变，数据量变化等，建议部署OCP监控下topsql资源消耗情况

#16

可以观察下慢的时间一般多久什么规律，是不是有其他定时任务这时候在跑。