cpu_count参数调整生效疑问

kevin_zhan · 2025 年7 月 16 日 06:29

【使用环境】测试环境（vm虚拟个人学习环境）
【 OB or 其他组件】observer
【使用版本】4.3.5.1
【问题描述】使用obclient -h192.168.1.117 -uroot@sys#newcluster -P2883 -pxxx -c -A oceanbase登录sys租户后，执行alter system set cpu_count=15;操作，再使用SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS;查看结果如下
±--------------±-------------+
| SVR_IP | CPU_CAPACITY |
±--------------±-------------+
| 192.168.1.117 | 15 |
| 192.168.1.118 | 15 |
| 192.168.1.119 | 16 |
±--------------±-------------+
想知道为什么119节点cpu_count并没有生效15，而117和118却生效了，我的虚机环境（4c 10g）

kevin_zhan · 2025 年7 月 16 日 06:32

设置cpu_count=0 再次查看如下
obclient(root@sys)[oceanbase]> alter system set cpu_count=0;
Query OK, 0 rows affected (0.020 sec)

obclient(root@sys)[oceanbase]> SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS;
±--------------±-------------+
| SVR_IP | CPU_CAPACITY |
±--------------±-------------+
| 192.168.1.118 | 4 |
| 192.168.1.117 | 4 |
| 192.168.1.119 | 16 |
±--------------±-------------+
3 rows in set (0.014 sec)

117和118节点和我实际分配的核数一直，但是119节点还是16，没有变化

辞霜 · 2025 年7 月 16 日 09:56

麻烦在19节点2881进去修改看看也是一样的情况么。麻烦提供一份trace日志
1）设置trace信息
SET ob_enable_show_trace=‘ON’;

2）执行sql。

3）获取上个命令的trace
select last_trace_id();

4）获取trace对应的节点
select query_sql,svr_ip from gv$ob_sql_audit where trace_id=‘第三步获取的trace信息’；

5）取对应的svr_ip节点过滤日志
grep “第三步获取的trace信息” observer.log*
grep “第三步获取的trace信息” rootservice.log*

6）提供日志信息即可。

兰葩奇 · 2025 年7 月 16 日 09:58

学习学习

kevin_zhan · 2025 年7 月 16 日 10:05

好的，我操作下回复，谢谢您

玉楼 · 2025 年7 月 16 日 11:13

119上是不是有租户unit?查下 select * from DBA_OB_UNITS

kevin_zhan · 2025 年7 月 16 日 11:34

[admin@obd ~]$ mysql -h 192.168.1.119 -uroot -P2881 -psystex@123 -c -A oceanbase
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 3222017998
Server version: 5.7.25 OceanBase_CE 4.3.5.1 (r101000042025031818-b6d5706eb3d2c5f501c7fa646ddbf32f3dc87069) (Built Mar 18 2025 18:12:30)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

MySQL [oceanbase]> SET ob_enable_show_trace=‘ON’;
Query OK, 0 rows affected (0.00 sec)

MySQL [oceanbase]> SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS;
±--------------±-------------+
| SVR_IP | CPU_CAPACITY |
±--------------±-------------+
| 192.168.1.119 | 16 |
| 192.168.1.117 | 16 |
| 192.168.1.118 | 16 |
±--------------±-------------+
3 rows in set (0.01 sec)

MySQL [oceanbase]> alter system set cpu_count=15;
SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS;Query OK, 0 rows affected (0.01 sec)

MySQL [oceanbase]> SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS;
±--------------±-------------+
| SVR_IP | CPU_CAPACITY |
±--------------±-------------+
| 192.168.1.119 | 16 |
| 192.168.1.117 | 15 |
| 192.168.1.118 | 16 |
±--------------±-------------+
3 rows in set (0.00 sec)

MySQL [oceanbase]> select last_trace_id();
±----------------------------------+
| last_trace_id() |
±----------------------------------+
| YB42C0A80177-00063A0354CEB917-0-0 |
±----------------------------------+
1 row in set (0.00 sec)

MySQL [oceanbase]> select query_sql,svr_ip from gv$ob_sql_audit where trace_id=‘YB42C0A80177-00063A0354CEB917-0-0’;
±----------------------------------------------±--------------+
| query_sql | svr_ip |
±----------------------------------------------±--------------+
| | 192.168.1.117 |
| | 192.168.1.119 |
| SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS | 192.168.1.119 |
| | 192.168.1.118 |
±----------------------------------------------±--------------+
4 rows in set (0.03 sec)

MySQL [oceanbase]>

117
[root@ob1 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log*
[root@ob1 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob1 ~]#

119
grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log*
grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob3 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log*
[root@ob3 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log
[root@ob3 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob3 ~]#

118
grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log*
grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob2 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/observer.log*
grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob2 ~]# grep “YB42C0A80177-00063A0354CEB917-0-0” /home/admin/newcluster/oceanbase/log/rootservice.log*
[root@ob2 ~]#
[root@ob2 ~]#
[root@ob2 ~]# 好像没过滤出来信息

kevin_zhan · 2025 年7 月 16 日 11:35

您好如下
obclient(root@sys)[oceanbase]> select * from DBA_OB_UNITS\G
*************************** 1. row ***************************
UNIT_ID: 1
TENANT_ID: 1
STATUS: ACTIVE
RESOURCE_POOL_ID: 1
UNIT_GROUP_ID: 1
CREATE_TIME: 2025-04-14 22:34:45.881699
MODIFY_TIME: 2025-04-14 22:34:45.881699
ZONE: zone1
SVR_IP: 192.168.1.117
SVR_PORT: 2882
MIGRATE_FROM_SVR_IP: NULL
MIGRATE_FROM_SVR_PORT: NULL
MANUAL_MIGRATE: NULL
UNIT_CONFIG_ID: 1
MAX_CPU: 3
MIN_CPU: 3
MEMORY_SIZE: 2147483648
LOG_DISK_SIZE: 2147483648
DATA_DISK_SIZE: NULL
MAX_IOPS: 9223372036854775807
MIN_IOPS: 9223372036854775807
IOPS_WEIGHT: 3
MAX_NET_BANDWIDTH: 9223372036854775807
NET_BANDWIDTH_WEIGHT: 3
*************************** 2. row ***************************
UNIT_ID: 2
TENANT_ID: 1
STATUS: ACTIVE
RESOURCE_POOL_ID: 1
UNIT_GROUP_ID: 1
CREATE_TIME: 2025-04-14 22:34:45.887229
MODIFY_TIME: 2025-04-14 22:34:45.887229
ZONE: zone2
SVR_IP: 192.168.1.118
SVR_PORT: 2882
MIGRATE_FROM_SVR_IP: NULL
MIGRATE_FROM_SVR_PORT: NULL
MANUAL_MIGRATE: NULL
UNIT_CONFIG_ID: 1
MAX_CPU: 3
MIN_CPU: 3
MEMORY_SIZE: 2147483648
LOG_DISK_SIZE: 2147483648
DATA_DISK_SIZE: NULL
MAX_IOPS: 9223372036854775807
MIN_IOPS: 9223372036854775807
IOPS_WEIGHT: 3
MAX_NET_BANDWIDTH: 9223372036854775807
NET_BANDWIDTH_WEIGHT: 3
*************************** 3. row ***************************
UNIT_ID: 3
TENANT_ID: 1
STATUS: ACTIVE
RESOURCE_POOL_ID: 1
UNIT_GROUP_ID: 1
CREATE_TIME: 2025-04-14 22:34:45.899903
MODIFY_TIME: 2025-04-14 22:34:45.899903
ZONE: zone3
SVR_IP: 192.168.1.119
SVR_PORT: 2882
MIGRATE_FROM_SVR_IP: NULL
MIGRATE_FROM_SVR_PORT: NULL
MANUAL_MIGRATE: NULL
UNIT_CONFIG_ID: 1
MAX_CPU: 3
MIN_CPU: 3
MEMORY_SIZE: 2147483648
LOG_DISK_SIZE: 2147483648
DATA_DISK_SIZE: NULL
MAX_IOPS: 9223372036854775807
MIN_IOPS: 9223372036854775807
IOPS_WEIGHT: 3
MAX_NET_BANDWIDTH: 9223372036854775807
NET_BANDWIDTH_WEIGHT: 3
3 rows in set (0.002 sec)

OB小太阳 · 2025 年7 月 16 日 13:32

蹲~

玉楼 · 2025 年7 月 17 日 17:04

119上没有其他的unit，已分配的CPU为3，预期修改到3以上应该都是OK的。详细问题需要日志定位了。

你这个流程没有完全按照辞霜的流程操作，trace拿错了。应该在执行alter system set cpu_count=15; 后立即执行select last_trace_id(); 。
你回复中的执行顺序拿到的trace是SELECT SVR_IP,CPU_CAPACITY FROM GV$OB_SERVERS; 而非 alter system set cpu_count=15;

kevin_zhan · 2025 年7 月 18 日 15:42

好的，我再补充下，这个命令不是很了解，不好意思

kevin_zhan · 2025 年7 月 18 日 16:28

cpu_count生效疑问.txt (34.2 KB)
您好请查看附件，谢谢

kevin_zhan · 2025 年7 月 18 日 16:29

cpu_count生效疑问.txt (34.2 KB)
您好这边重新按要求重做了，请查阅附件，谢谢

辞霜 · 2025 年7 月 18 日 16:46

alter修改一下，然后重启集群看看，文档有描述可能存在不动态生效