在ocp监控中发现有些insert语句,有的时候快有的时候慢,想知道这种该从什么角度去分析哪?按正常来讲,insert不应该慢啊。
1 个赞
慢SQL日志中看看,耗时在哪里,在看看那个时间是不是转储时间,内存不足,写入限速。
业务发布新版本,出现新的 SQL 逻辑
业务有新发布上线时,会有新 SQL 产生,在有些情况下可能存在一些未经 review 的慢 SQL 在生产上占用了过多资源,影响了核心业务。此时需要排查数据库中的慢 SQL 来定位问题所在,并进行后续优化处理。
- 通过 OCP 查找慢 SQL。可以在 OCP 的 TOP SQL 页面查看最近一段时间耗时、执行次数最高的查询,从高到低进行排序,对于计划走错的 SQL直接在线绑定,具体操作请参见 可疑 SQL 诊断 ;对于需要限流的 SQL,需要结合业务研发的确认信息,定位可以进行限流的SQL。
- 在命令行查找慢 SQL。
- 查询特定租户下消耗 CPU 最多的 top sql。
SELECT
sql_id,
avg(execute_time) avg_exec_time,
count(*) cnt,
avg(execute_time - TOTAL_WAIT_TIME_MICRO) cpu_time,
RETRY_CNT,QUEUE_TIME,IS_HIT_PLAN
FROM
OCEANBASE.V$OB_SQL_AUDIT
WHERE
tenant_id = 1002
GROUP BY
1
ORDER BY
(avg_exec_time * cnt) desc
limit
5;
说明
- 其中 EXECUTE_TIME 值,如果值过大,考虑存在等待事件或逻辑读次数异常多。
- RETRY_CNT 字段即 retry 次数,如果次数很多,则可能有锁冲突或切主等情况。
- QUEUE_TIME 过大,则表明 CPU 资源不够用。
- GET_PLAN_TIME 为获取执行计划的时间,如果如果时间很长,一般会伴随 IS_HIT_PLAN=0,表示没有命中 plan。
- 其他相关查询。OceanBase 提供两张虚拟表
V$OB_SQL_AUDIT
,GV$OB_SQL_AUDIT
记录最近一段时间 SQL 执行历史,V$OB_SQL_AUDIT 存储本机的 SQL 执行历史,GV$OB_SQL_AUDIT 存储整个集群的 SQL 执行历史。可以根据需要进行相关查询。 - 查询 GV$OB_SQL_AUDIT 表,如查询某租户执行时间大于1s (1000000微秒)的 SQL。
SELECT * FROM oceanbase.GV$OB_SQL_AUDIT WHERE tenant_id= <tenantid> AND elapsed_time> 1000000 limit 10;
- 查询 SQL 执行时间按秒分布的直方图。
SELECT round(elapsed_time/1000000), count(*) FROM oceanbase.V$OB_SQL_AUDIT WHERE tenant_id = <tenant_id> GROUP BY 1;
- 在 OceanBase 日志中查找慢 SQL。OceanBase 中 SQL 执行时间超过 trace_log_slow_query_watermark (系统参数)的,在 observer 日志中都会打印 slow query 消息,该参数默认值为 100ms。可以通过 observer 日志查找慢 SQL。这种方式没有上述两种方法高效直观,但在一些情况下也有助于一些问题的问题,例如当 sql_audit 中的缓存已经淘汰时。记录慢 SQL 日志的位置:
/home/admin/oceanbase/log
- 看日志中所有的 slow query。
fgrep '[slow query]' observer.log |sed -e 's/|/\n/g' | more
- 根据 trace_id 查询某个 slow query。
fgrep "<trace_id>" observer.log |sed -e 's/|/\n/g' | more
在observer.log里搜索慢SQL
https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001699942
如果topSql里重试次数 >0 ,大概率因为锁冲突