oceanbase3节点集群性能问题

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

oceanbase3节点集群，2个节点sql latency在2ms左右，1个节点sql latency在3s左右，这代表性能有问题吗

#3

根据您提供的信息，3节点集群中2个节点的SQL延迟在2ms左右，而另一个节点的SQL延迟在3s左右，这确实表明存在性能问题。这种显著的延迟差异可能是由以下几个原因造成的：

  1. 节点间负载不均衡：某些节点可能承担了更多的查询负载，导致其性能下降。您可以运行以下SQL语句来查询SQL流量在各OBServer节点间的分布情况及QPS，以确定是否存在负载不均衡的问题：

    obclient> SELECT/*+ PARALLEL(15)*/t2.zone, t1.svr_ip,  COUNT(*) AS RPC_COUNT,
AVG(t1.elapsed_time), AVG(t1.queue_time)
FROM oceanbase.GV$OB_SQL_AUDIT t1, __all_server t2
WHERE t1.svr_ip = t2.svr_ip
AND tenant_id = 1001
AND SQL_ID = 'BF7AA13A28DF50BA5C33FF19F1DBD8A9'
AND IS_EXECUTOR_RPC = 0
AND request_time > (time_to_usec(now()) - 1000000)
AND request_time < time_to_usec(now())
GROUP BY t1.svr_ip;

  2. 节点资源使用率过高：某个节点的CPU、内存或磁盘I/O资源可能已经达到了瓶颈。您可以检查该节点的资源使用情况，特别是CPU使用率。如果某个节点的CPU使用率接近100%，则可能是导致性能下降的原因之一。

  3. 特定SQL语句的性能问题：某个特定的SQL语句可能在该节点上执行效率低下。您可以查询GV$OB_SQL_AUDIT视图，抓取信息进行分析，定位到问题SQL。例如，可以查看该SQL的平均耗时、CPU使用量等指标，结合EXPLAIN信息以及相关表和视图的DDL定义，确定影响性能的原因。

  4. 网络延迟：虽然同机房的网络延迟通常较低，但如果节点之间的网络通信出现问题，也可能导致性能下降。您可以检查节点之间的网络延迟，确保网络通信正常。

  5. 计划缓存问题：如果某个节点的计划缓存中存在不合理的执行计划，也可能导致性能问题。您可以尝试清除计划缓存，或者手动绑定正确的执行计划。

建议您按照上述步骤进行排查，以确定具体的问题原因，并采取相应的优化措施。如果问题仍然无法解决，建议使用OceanBase敏捷诊断工具obdiag收集诊断信息，以便进一步分析。

详情请参考:

  1. 查询 SQL 流量分布情况及 QPS
  2. SQL Explain 优化实践
  3. 数据库应急概述
  4. 租户请求队列积压
  5. 计划缓存概述
  6. 少数派节点故障
  7. 常见的业务问题
  8. OceanBase 集群高可用部署方案简介
  9. SQL 调优典型场景和案例
  10. ODP 性能分析
#4

这个sql_id如何确定

#5

要确定具体的 SQL_ID，您可以使用 GV$OB_SQL_AUDIT 视图来查询一段时间内的所有SQL语句及其相关信息。通过这些信息，您可以找到导致性能问题的具体SQL语句及其 SQL_ID。以下是几种方法来确定 SQL_ID：

方法一：查询所有SQL语句及其 SQL_ID

您可以查询 GV$OB_SQL_AUDIT 视图，获取一段时间内所有SQL语句的 SQL_ID 及其执行时间等信息。例如：

obclient> SELECT SQL_ID, COUNT(*), AVG(elapsed_time), MAX(elapsed_time), MIN(elapsed_time)
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE tenant_id = 1001
AND request_time > (time_to_usec(now()) - 1000000)
AND request_time < time_to_usec(now())
GROUP BY SQL_ID
ORDER BY AVG(elapsed_time) DESC
LIMIT 10;

这条SQL语句会返回最近1秒内执行的所有SQL语句的 SQL_ID，并按平均执行时间降序排列，显示前10条记录。您可以根据这些信息找到执行时间较长的SQL语句及其 SQL_ID。

方法二：查询特定时间段内耗时超过某个阈值的SQL

如果您已经知道某个时间段内存在性能问题，可以查询这段时间内耗时超过某个阈值的SQL语句。例如：

obclient> SELECT SQL_ID, elapsed_time, usec_to_time(request_time), substr(query_sql, 1, 50)
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE tenant_id = 1001
AND elapsed_time > 100000
AND request_time > time_to_usec('2021-10-08 12:00:00')
ORDER BY elapsed_time DESC
LIMIT 40;

这条SQL语句会返回2021年10月8日12:00:00之后，执行时间超过100毫秒的SQL语句及其 SQL_ID，并按执行时间降序排列，显示前40条记录。

方法三：查询所有SQL语句的平均执行时间

您可以查询所有SQL语句的平均执行时间，找出执行时间最长的SQL语句。例如：

obclient> SELECT/*+ PARALLEL(15)*/avg_exe_usec, svr_ip, svr_port, sql_id, plan_id
FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
WHERE tenant_id = 1001
ORDER BY avg_exe_usec DESC
LIMIT 3;

这条SQL语句会返回平均执行时间最长的前3条SQL语句及其 SQL_ID。

综合分析

通过上述方法，您可以找到导致性能问题的具体SQL语句及其 SQL_ID。然后，您可以将这些 SQL_ID 代入到您之前提到的SQL语句中，进一步分析这些SQL语句在各个节点上的执行情况。

希望这些方法能帮助您确定具体的 SQL_ID 并解决问题。如果还有其他疑问，请随时提问。

检索到的文档如下:

  1. GV$OB_SYS_TIME_MODEL
  2. 查询 SQL 流量分布情况及 QPS
  3. V$OB_SYS_TIME_MODEL
  4. 分析系统或某个 SQL 的执行是否出现大量不合理远程执行请求
  5. GV$OB_SQL_AUDIT
  6. 查询排名 TOP N 的 SQL
  7. 负载均衡
  8. GV$OB_KV_GROUP_COMMIT_STATUS
  9. V$OB_KV_GROUP_COMMIT_STATUS

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

#6

哈哈，当你在怀疑它有问题的时候，不妨试试敏捷诊断工具obdiag 进行巡检一下，或许能排除点障碍。
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001491192