sys租户cpu使用率过高告警

【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.2.1
【问题描述】sys租户的资源是4c5g3副本，3个zone是随机均等的。今天发现ocp告警，sys租户cpu使用率较高，发现zone3的cpu持续在90%以上，甚至有时超过110%，其余2个zone的cpu使用较低，总体cpu使用率30%左右。通过sql诊断发现有个sql执行次数非常多，且消耗了非常多的cpu，请问这个sql是用于什么功能，是否可以限流。

image815×264 24.5 KB

image812×253 11.2 KB

image808×231 11.8 KB

image1634×520 37.8 KB

SELECT
/+READ_CONSISTENCY(WEAK)/
*
FROM
oceanbase.__all_virtual_proxy_schema
WHERE
tenant_name = ?
AND database_name = ?
AND table_name = ?
AND tablet_id = ?
ORDER BY
role ASC
LIMIT
?

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

根因分析场景: SQL性能问题
根因分析命令: obdiag rca run --scene=sql_performance --env “{db_connect=’-h127.0.0.1 -P2881 -usys@sys -p****** -Dsys’, trace_id=‘Yxx’}” （此命令为示例，具体需要根据实际环境调整）

日志采集场景: 高CPU
日志采集命令: obdiag gather scene run --scene=observer.cpu_high

推荐使用 obdiag 工具进行日志采集和根因分析，并且将采集到的日志提供给我们以便确认问题所在。以下命令可以帮助您定位高 CPU 使用率的具体原因以及高频执行 SQL 的详细信息。

为了更好地帮助您解决问题，请您按照以下步骤操作并提供相关信息：

1. 执行上述 obdiag gather 命令后，请将生成的日志压缩包上传或发送给我们，以便进一步分析。
2. 请提供该高频执行 SQL 的具体语句及其执行计划（可以通过 explain 命令获取）。
3. 该 SQL 是否可以优化？例如是否存在索引缺失、全表扫描等情况？
4. 您是否已经尝试过对该 SQL 进行限流？如果尝试过，请描述具体的限流方法及效果。
5. 该 zone 的硬件配置（如 CPU 核心数、内存大小等）与其他两个 zone 是否一致？如果不一致，请说明差异。
6. 除了该高频 SQL 外，是否有其他 SQL 或任务在该 zone 上运行导致资源竞争？

通过以上信息的收集，我们可以更准确地定位问题并给出优化建议。

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

通过topsql发现，该sql执行得太频繁了，平均每秒执行1400多次，执行这个sql的proxyro用户，请问这种情况是正常的吗？

根据文档库中的信息，以下是对您问题的分析和解答：

1. SQL 执行频率过高是否正常

• 根据您提供的信息，proxyro 用户执行的 SQL 每秒高达 1400 次，这属于高频短查询场景。这种情况下，需要结合业务逻辑判断该 SQL 的执行频率是否合理。
• 如果该 SQL 是业务核心逻辑的一部分（例如频繁读取某些元数据或状态信息），则可能属于正常现象。但如果该 SQL 并非业务核心逻辑，则可能存在优化空间。

2. SQL 功能分析

• 您提到的 SQL 是：

  SELECT /*+READ_CONSISTENCY(WEAK)*/
  *
  FROM oceanbase.__all_virtual_proxy_schema
  WHERE tenant_name = ?
    AND database_name = ?
    AND table_name = ?
    AND tablet_id = ?
  ORDER BY role ASC
  LIMIT ?;
  

  • 该 SQL 查询的是 __all_virtual_proxy_schema 虚拟表，通常用于获取与 Proxy 相关的元数据信息（如租户、数据库、表等）。
  • READ_CONSISTENCY(WEAK) 提示使用弱一致性读取，适合对实时性要求不高的场景。
  • 如果该 SQL 被频繁调用，可能是某些业务逻辑或中间件（如 OBProxy）在频繁刷新元数据。

3. 是否可以限流

• OCP Express 的 SQL 限流功能
  根据文档片段 4 的描述，OCP Express 提供了针对异常 SQL 的限流功能。您可以使用 OCP Express 对该 SQL 进行限流操作，以减少其对系统资源的占用。
  • 具体步骤：通过 OCP Express 的 SQL 诊断功能找到该 SQL，并设置限流规则。
• 手动限流方法
  如果未使用 OCP Express，也可以通过以下方式手动限流：
  • 在业务层增加缓存机制，减少对该 SQL 的直接调用频率。
  • 修改 SQL 的执行逻辑，例如增加时间间隔或批量处理。

4. 优化建议

• 业务优化建议
  • 检查业务逻辑中是否存在不必要的高频调用。如果该 SQL 的结果变化不频繁，可以考虑在业务层引入缓存机制，降低调用频率。
• 数据库优化建议
  • 确保该 SQL 的查询条件（如 tenant_name, database_name, table_name, tablet_id）上有合适的索引，避免全表扫描。
  • 如果该 SQL 的执行计划存在不合理之处，可以通过 EXPLAIN 分析并优化。
• 资源隔离建议
  • 如果该 SQL 的高频率调用确实无法避免，可以考虑将其分配到独立的租户或资源池中，避免影响其他业务。

5. 总结

• 该 SQL 的高频率执行是否正常，取决于其业务用途。如果并非业务核心逻辑，建议优化业务逻辑或引入缓存机制。
• 可以通过 OCP Express 或手动方式对该 SQL 进行限流。
• 建议进一步分析该 SQL 的执行计划和业务场景，确保其性能开销在合理范围内。

如果您需要更详细的分析，请提供以下信息：

• 该 SQL 的具体执行计划（可通过 EXPLAIN 获取）。
• 该 SQL 的调用方（业务代码或中间件）及其调用逻辑。
• 是否已经尝试过优化措施及其效果。

具体信息可参考以下文档:

1. 分析系统或某个 SQL 的执行是否出现大量不合理远程执行请求
2. SQL 调优典型场景和案例
3. SQL 查询导致的异常
4. 诊断分析
5. 并行执行问题诊断
6. JOIN 表使用建议
7. 定位和分析慢查询（二）
8. 查询排名 TOP N 的 SQL
9. GV$OB_SQL_AUDIT

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

sys租户下 查一下这个信息
select * from __all_virtual_processlist where tenant = ‘sys’ and user = ‘ocp_monitor’ and command != ‘sleep’

__all_virtual_proxy_schema 存储了分区和svrip的对应关系，当解析sql获取表名后缓存中没有对应的机器ip会去查这张表。平均每秒执行1400多次这个持续了多久？如果长期保持可能是出发了啥bug。

image1107×215 12.7 KB

这个表的频率很高。 是不是程序里面 时间 间隔写错了

查询的结果：
| 3226018355 | ocp_monitor | sys | 127.0.0.1:43192 | oceanbase | Query | 65D3F5BF2B8448B0CFDD69684B19BBEE | 0.057241 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) / time_to_usec(now()) as collect_time, tenant_id, db_id, plan_id, outline_id, avg_exe_usec, slowest_exe_usec, slow_count, hit_count, executions, disk_reads, direct_writes, buffer_gets, application_wait_time, concurrency_wait_time, user_io_wait_time, rows_processed, elapsed_time, cpu_time, large_querys, delayed_large_querys, table_scan, timeout_count, time_to_usec(first_load_time) as first_load_time, sql_id, type, plan_hash, schema_version, 0 as merged_version, plan_size, outline_data, query_sql from V$OB_PLAN_CACHE_PLAN_STAT where (unix_timestamp(now()) - unix_timestamp(last_active_time)) < 243600 and tenant_id = 1041 and plan_id > 114463and object_type = ‘sql_plan’ order by plan_id limit 4000 | 10.252.210.150 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 3724495 | NULL | YB420AFCD296-0006343127DFFD26-0-0 | | 0.057311 | 0 | 0 | | | | 1 | 286 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 43192 | | NULL | 0.057567 |
| 3222383380 | ocp_monitor | sys | 127.0.0.1:39132 | oceanbase | Query | 923D949AF30C198C39816EF7AFFF6975 | 0.113427 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) / sql_id, statement from V$OB_PLAN_CACHE_PLAN_STAT where svr_ip = ‘10.252.210.163’ and svr_port = 2882 and sql_id = ‘98321C13F557E6241FB3BC79BAAE0180’ | 10.252.210.163 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 2946115 | NULL | YB420AFCD2A3-00062C51A558CB9C-0-0 | | 0.113471 | 0 | 0 | | | | 1 | 369 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 39132 | | NULL | 0.114418 |
| 3223370493 | ocp_monitor | sys | 127.0.0.1:13046 | oceanbase | Query | B7220EB263020F060EF060DD2792BDC5 | 0.07453 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) / distinct sql_id, statement from V$OB_PLAN_CACHE_PLAN_STAT where svr_ip = ‘10.252.210.156’ and svr_port = 2882 and sql_id in (‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’) | 10.252.210.156 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 3216175 | NULL | YB420AFCD29C-000631129097842E-0-0 | | 0.074604 | 0 | 0 | | | | 1 | 142 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 13046 | | NULL | 0.087575 |
| 3221979193 | ocp_monitor | sys | 10.252.158.68:57084 | oceanbase | Query | 27644E0EB1E297E628E1032986601197 | 2.126029 | ACTIVE | select I.index_name, I.index_type, I.uniqueness, I.status, I.table_owner, group_concat(C.column_name order by column_position separator ‘,’) as column_name from cdb_indexes I left join cdb_ind_columns C on I.table_owner = C.table_owner and I.table_name = C.table_name and I.index_name = C.index_name and I.con_id = C.con_id where I.con_id = 1080and I.table_owner = ‘ncms_jx’ and I.table_name = ‘ele_accrual_billamount’ and I.status = ‘VALID’ group by index_name | 10.252.210.165 | 2882 | 2881 | NULL | NULL | 10.252.158.68 | % | 0 | 775888 | NULL | YB420AFCD2A5-00062CA932D91E0A-0-0 | | 2.126084 | 0 | 0 | | | | 1 | 701066 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 434 | 0 | 57084 | | NULL | 2.126265 |
| 3225824270 | ocp_monitor | sys | 127.0.0.1:56810 | oceanbase | Query | B7220EB263020F060EF060DD2792BDC5 | 0.125154 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) / distinct sql_id, statement from V$OB_PLAN_CACHE_PLAN_STAT where svr_ip = ‘10.252.210.172’ and svr_port = 2882 and sql_id in (‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘0CAEAD5E6ED70B0145A9096C88C31DF6’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’, ‘5E5C065BF37472A85B7A3F45B73E16F1’) | 10.252.210.172 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 1505512 | NULL | YB420AFCD2AC-000632B6C1753DAF-0-0 | | 0.125223 | 0 | 0 | | | | 1 | 120 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 56810 | | NULL | 0.13905 |
| 3225823291 | ocp_monitor | sys | 127.0.0.1:56806 | oceanbase | Query | 201D9ED0465032D54BCDC648C5701EBB | 0.002911 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) / ifnull(max(request_id), 0) from v$sql_plan_monitor where con_id = 1103 | 10.252.210.172 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 1505526 | NULL | YB420AFCD2AC-000632B6C1C53D8E-0-0 | | 0.002999 | 0 | 0 | | | | 1 | 273 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 56806 | | NULL | 0.003303 |
| 3225825844 | ocp_monitor | sys | 127.0.0.1:56818 | oceanbase | Query | 541A86125E22C2FD8708EA4CF099091F | 0.035492 | ACTIVE | select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) */ ifnull(max(request_id), 0) max_request_id, ifnull(min(request_id), 0) min_request_id from (select request_id from v$sql_plan_monitor where (unix_timestamp(first_refresh_time) *1000000) >= 1744791819000000 and (unix_timestamp(first_refresh_time) 1000000) < 1744791879000000 and request_id > 0 and con_id = 1040 order by request_id limit 4000) t | 10.252.210.172 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 1505528 | NULL | YB420AFCD2AC-000632B6C1D53D85-0-0 | | 0.03559 | 0 | 0 | | | | 1 | 274 | 1 | 1 | 1 | 10 |SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 56818 | | NULL | 0.04607 |
| 3225322719 | ocp_monitor | sys | 127.0.0.1:52066 | oceanbase | Query | 8B22D2484ECE7D89B2641D9E852CE9A4 | 0.000436 | ACTIVE |
select /+ MONITOR_AGENT QUERY_TIMEOUT(10000000) */
svr_ip,
sql_id,
tenant_id,
tenant_name,
user_id,
user_name,
db_id,
db_name,
plan_id,
trace_id,
sid,
client_ip,
client_port,
user_client_ip,
request_time,
request_id,
elapsed_time,
execute_time,
total_wait_time_micro,
wait_time_micro,
get_plan_time,
affected_rows,
return_rows,
partition_cnt,
ret_code,
(case when ret_code = 0 then 0 else 1 end) as fail_count,
(case when ret_code = -4012 then 1 else 0 end) as ret_code_4012_count,
(case when ret_code = -4013 then 1 else 0 end) as ret_code_4013_count,
(case when ret_code = -5001 then 1 else 0 end) as ret_code_5001_count,
(case when ret_code = -5024 then 1 else 0 end) as ret_code_5024_count,
(case when ret_code = -5167 then 1 else 0 end) as ret_code_5167_count,
(case when ret_code = -5217 then 1 else 0 end) as ret_code_5217_count,
(case when ret_code = -6002 then 1 else 0 end) as ret_code_6002_count,
event,
p1,
p2,
p3,
p1text,
p2text,
p3text,
(case event when ‘system internal wait’ then wait_time_micro else 0 end) as event_0_wait_time,
(case event when ‘mysql response wait client’ then wait_time_micro else 0 end) as event_1_wait_time,
(case event when ‘sync rpc’ then wait_time_micro else 0 end) as event_2_wait_time,
(case event when ‘db file data read’ then wait_time_micro else 0 end) as event_3_wait_time,
total_waits,
rpc_count,
plan_type,
(case when plan_type=1 then 1 else 0 end) as plan_type_local_count,
(case when plan_type=2 then 1 else 0 end) as plan_type_remote_count,
(case when plan_type=3 then 1 else 0 end) as plan_type_dist_count,
is_inner_sql,
is_executor_rpc,
is_hit_plan,
consistency_level,
(case when is_inner_sql=1 then 1 else 0 end) as inner_sql_count,
(case when is_executor_rpc = 1 then 1 else 0 end) as executor_rpc_count,
(case when is_hit_plan=1 then 0 else 1 end) as miss_plan_count,
(case consistency_level when 3 then 1 else 0 end) as consistency_level_strong,
(case consistency_level when 2 then 1 else 0 end) as consistency_level_weak,
net_time,
net_wait_time,
queue_time,
decode_time,
application_wait_time,
concurrency_wait_time,
user_io_wait_time,
schedule_time,
row_cache_hit,
bloom_filter_cache_hit,
block_cache_hit,
disk_reads,
retry_cnt,
table_scan,
memstore_read_row_count,
ssstore_read_row_count,
query_sql, 0 as block_index_cache_hit, expected_worker_count, used_worker_count, request_memory_used, tx_id as transaction_hash, effective_tenant_id, params_value, flt_trace_id from V$OB_SQL_AUDIT where request_id = 539839246 and tenant_id = 1062 | 10.252.210.168 | 2882 | 2881 | NULL | NULL | 127.0.0.1 | % | 0 | 2548163 | NULL | YB420AFCD2A8-0006326D36990829-0-0 | | 0.000504 | 0 | 0 | | | | 1 | 368 | 1 | 1 | 1 | 10 | SAMPLE_AND_SLOW_QUERY | NULL | NULL | NULL | 101 | 0 | 52066 | | NULL | 0.000744 |

这个是不是ODP那边缓存的时间比较短，导致每次查询的时候都会去查这张表？

不会的，过期了才会来查询这个表。

我们的集群QPS大概在30000，按照这个qps，这个表的qps在1500左右，这个算正常吗。集群有35个租户，每个租户上平均有850张表。
按照这个来算的话，每个租户的请求查这张表的概率还是挺大的。
ODP控制缓存过期有哪些参数，时候可以调整缓存过期时间。

集群总内存cpu多少，每个表都是分区表还是非分区？磁盘使用量多少？
登录proxysys租户show一下proxy的参数保持个附件发一下

集群总CPU 1440c，内存7500G，每个表是非分区表，数据磁盘使用量6.7T。
proxyconfig.txt (24.8 KB)

内存是不是错了 7T多么？？

集群的总内存差不多这么多。

有资源限制配置吧

grep “ROUTE” obproxy_diagnosis.log* -c
提供一下日志信息，看看是不是路由有很多不准确

OBPROXY_LOG_ob_pro_obproxy_rw_10.252.210.161_20250416121039_20250416181039.zip (11.5 MB)
这是其中搞一台ODP的日志

您说的资源限制是资源隔离？

client_max_connections 8192 内存大小是 3G
proxy_mem_limited 3G

能发下内存的 监控不 ？