执行报错表不存在
1146 - Table ‘oceanbase.__all_server’ doesn’t exist
业务分区leader在3台observer基本是均衡的
1.修改了下，用sys租户查询下
SELECT/*+ PARALLEL(15)*/t2.zone, t1.svr_ip, t1.TENANT_ID, COUNT(*) AS QPS,
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 IS_EXECUTOR_RPC = 0
AND request_time > (time_to_usec(now()) - 1000000)
AND request_time < time_to_usec(now())
GROUP BY t1.TENANT_ID,t1.svr_ip ORDER BY t2.zone;
2.查询下版本
show variables like '%version_comment%';
- 确认下CPU高的节点 的 IP 是不是 192.168.90.6？
并在这个节点上执行
top -H -p 2185069 # observer 的 PID，按 P 排序
1 个赞
OceanBase_CE 4.2.5.3 (r103000022025033117-35332d18a11e56f660c3be9383a5682322cd7949) (Built Mar 31 2025 18:00:08)
差不多是90.6，有时候90.7会最高
90.6
90.7
DD
看着不高啊，现在是不是不高了？
另外一套环境，没有那么高
这个是正常的，比如某一台有后台任务 稍微高一些，这个没有分析的必要
你最开始发的那一套其中一台明显要高很多，有分析的必要
1 个赞
逻辑清晰，论据充分，非常有说服力。
回答的相当详细
热情
1.显示线程名
ps -T -p $(pidof observer) -o tid,comm,pcpu,time --sort=-pcpu | head -35
2.看最热的函数名
perf top -p $(pidof observer)
3. 最近 1 分钟各节点的请求量分布
SELECT svr_ip, COUNT(*) AS req_cnt
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE request_time > TIME_TO_USEC(NOW()) - 60000000
GROUP BY svr_ip;
4.各租户实际 CPU 消耗（区分是哪个租户在烧）
SELECT svr_ip, con_id AS tenant_id, value/100 AS cpu_cores
FROM oceanbase.GV$SYSSTAT
WHERE name = 'cpu usage'
ORDER BY value DESC;
SELECT svr_ip, COUNT(*) AS req_cnt
→ FROM oceanbase.GV$OB_SQL_AUDIT
→ WHERE request_time > TIME_TO_USEC(NOW()) - 60000000
→ GROUP BY svr_ip;
±---------------------------------±--------+
| svr_ip | req_cnt |
±---------------------------------±--------+
| fc00:305:200:500a:73:0:d6a6:7d15 | 719 |
| fc00:305:200:500a:73:0:d6bb:38dc | 736 |
| fc00:305:200:500a:73:0:d6d1:8c0b | 7682 |
±---------------------------------±--------+
3 rows in set (0.069 sec)
obclient [oceanbase]> SELECT svr_ip, COUNT(*) AS req_cnt FROM oceanbase.GV$OB_SQL_AUDIT WHERE request_time > TIME_TO_USEC(NOW()) - 60000000 GROUP BY svr_ip;
±---------------------------------±--------+
| svr_ip | req_cnt |
±---------------------------------±--------+
| fc00:305:200:500a:73:0:d6a6:7d15 | 687 |
| fc00:305:200:500a:73:0:d6bb:38dc | 710 |
| fc00:305:200:500a:73:0:d6d1:8c0b | 7641 |
±---------------------------------±--------+
3 rows in set (0.047 sec)
obclient [oceanbase]>
obclient [oceanbase]>
obclient [oceanbase]>
obclient [oceanbase]> SELECT svr_ip, COUNT(*) AS req_cnt FROM oceanbase.GV$OB_SQL_AUDIT WHERE request_time > TIME_TO_USEC(NOW()) - 60000000 GROUP BY svr_ip;
±---------------------------------±--------+
| svr_ip | req_cnt |
±---------------------------------±--------+
| fc00:305:200:500a:73:0:d6a6:7d15 | 747 |
| fc00:305:200:500a:73:0:d6bb:38dc | 745 |
| fc00:305:200:500a:73:0:d6d1:8c0b | 9013 |
±---------------------------------±--------+
3 rows in set (0.068 sec)
[root@node001 ~]# ps -T -p 2185069 -o tid,comm,pcpu,time --sort=-pcpu | head -35
TID COMMAND %CPU TIME
2185069 observer 0.0 00:00:03
2185084 TimerWK0 1.5 01:34:03
2185085 TimerWK1 1.5 01:34:09
2185086 TimerWK2 1.5 01:34:13
2185087 TimerWK3 1.5 01:34:10
2185088 TimerSvr 0.0 00:06:02
2185089 qth_mgr 0.0 00:00:37
2185090 OB_PLOG 0.1 00:08:27
2185091 SyslogCompress 0.0 00:00:08
2185156 LogLimiterRefre 0.0 00:01:21
2185157 obdal 0.0 00:00:00
2185158 obdal 0.0 00:00:00
2185159 obdal 0.0 00:00:00
2185160 obdal 0.0 00:00:00
2185161 obdal 0.0 00:00:00
2185162 obdal 0.0 00:00:00
2185163 obdal 0.0 00:00:00
2185164 obdal 0.0 00:00:00
2185165 obdal 0.0 00:00:00
2185166 obdal 0.0 00:00:00
2185167 obdal 0.0 00:00:00
2185168 obdal 0.0 00:00:00
2185169 obdal 0.0 00:00:00
2185170 obdal 0.0 00:00:00
2185171 obdal 0.0 00:00:00
2185172 obdal 0.0 00:00:00
2185173 obdal 0.0 00:00:00
2185174 obdal 0.0 00:00:00
2185175 obdal 0.0 00:00:00
2185176 obdal 0.0 00:00:00
2185177 obdal 0.0 00:00:00
2185178 IO_GETEVENT0 0.0 00:00:04
2185179 IO_GETEVENT0 0.0 00:00:05
2185180 IO_GETEVENT0 0.0 00:00:04
perf 没有这个命令
就一个主租户sys
node001 CPU 高的直接原因就是：90% 的 SQL 请求都打到了这台机器上
只有1个租户，sys租户，是业务表建到了sys租户吗？
– 在当前集群执行，sys租户执行
1.
SELECT tenant_name, primary_zone FROM oceanbase.DBA_OB_TENANTS;
2.
SELECT svr_ip, COUNT(*) FROM oceanbase.CDB_OB_TABLE_LOCATIONS
WHERE role='LEADER' GROUP BY svr_ip;
3.
SELECT tenant_id, svr_ip, COUNT(*) AS req_cnt
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE request_time > TIME_TO_USEC(NOW()) - 60000000
GROUP BY tenant_id, svr_ip ORDER BY req_cnt DESC;
4.
SELECT sql_id, COUNT(*) AS cnt,
ROUND(AVG(elapsed_time)) AS avg_us,
SUBSTR(query_sql, 1, 100) AS sql_text
FROM oceanbase.GV$OB_SQL_AUDIT
WHERE svr_ip = 'fc00:305:200:500a:73:0:d6d1:8c0b'
AND request_time > TIME_TO_USEC(NOW()) - 60000000
GROUP BY sql_id ORDER BY cnt DESC LIMIT 10;
5.
SELECT svr_ip, user_client_ip, COUNT(*) AS sess_cnt
FROM oceanbase.GV$OB_PROCESSLIST
GROUP BY svr_ip, user_client_ip ORDER BY sess_cnt DESC;
6.在node001
top -H -b -n 1 -o %CPU -p 2185069 | head -25
CDB_OB_TABLE_LOCATIONS: 2910 个 LEADER 全在 ...d6d1:8c0b（只返回 1 行！）
DBA_OB_TENANTS: 只有 sys 租户
GV$OB_SQL_AUDIT: tenant_id 全是 1（sys）
top -H: 满转线程全是 T1_PX_G0 / T1_L0_G0（T1 = tenant 1 = sys）
根因：业务表建在 sys 租户 → 天然无法负载均衡
只要业务表在 sys 租户里，无论怎么调参数、无论 OBProxy 怎么配，都不可能实现三节点负载均衡。 这是架构约束，不是配置问题。
原理：
1.sys 租户永远只有一个日志流 LS 1 （系统日志流），不会像用户租户那样创建 LS 1001/1002/1003。
2.所有表的 tablet 都只能挂在 LS 1 上，而一个 LS 的 Leader 只能在一台机器上 → 2910 个 tablet Leader 100% 集中，物理上无法分散。
3.primary_zone = RANDOM 对 sys 租户只是"随机挑一个 zone 放 Leader"，不是"打散到三个 zone"。因为只有一个 LS，随机的结果就是随机选中了 node001。
4. sys 租户不参与分区均衡（partition balance）和 transfer ，enable_rebalance 对它无效
建议：
强烈不建议业务表放到sys租户。sys 租户还有几个额外风险：资源规格通常很小（不隔离、内存/CPU 受限）、承担 RootService 元数据管理职责，业务压满会拖慢整个集群的元数据操作（DDL、位置缓存、心跳），甚至影响升级和运维
另外:
226361 T1_PX_G0 99.9% 累计 950 分钟
236799 T1_PX_G0 99.9% 累计 2350 分钟 ← 39 小时的 CPU！
2144864 T1_PX_G0 99.9% 累计 140 分钟
3 个 PX（并行执行）线程各自钉在 100%，累计消耗几十小时 CPU 。整机只有 22% us、77% idle，说明不是业务量大，而是少数几个 SQL 在长时间空转 。结合 Top SQL 里这条：
SELECT uid, SUBSTRING(uid, 105, 32) AS uuid FROM hhit_asset
WHERE SUBSTRING(uid, 105, 32) IN ('...') -- 平均 58ms，489 次/分钟
WHERE 条件里对列做了 SUBSTRING() 函数运算，索引完全失效，必然全表扫描 ，一旦触发并行执行就会长期占满 CPU 核。还有 UPDATE hhit_agent （平均 178ms / 184ms ）也明显偏慢。
后续：
1.创建业务租户，将业务表迁移到业务租户
2.集中优化慢sql
多装几台OBProxy然后对OBProxy做强制路由到一台节点上面，然后将部分业务迁移到其他做过强制路由的OBProxy上面可行嘛
有没有办法找出空转的sql
不可行，需要将业务表从sys租户迁出来，迁到新建的业务租户