2. 问题背景与现象描述先说结论OCP 里资源分配看起来生效了但实际业务侧完全没按配置走这属于典型的“配置下发链路断点”问题不是 OceanBase 本身资源管理能力不行而是中间某一环把配置给“吞”了。我在实际运维中遇到的这个案例现象非常有代表性。集群里有几个租户业务方反馈某个大查询跑起来之后把 CPU 和 IO 都打满了旁边的租户延迟直接飙到几秒。我去 OCP 控制台查看资源隔离配置发现各项 limit 值都设置得清清楚楚资源池的 unit 规格也配了看起来一切正常。但实测下来那个大查询依然在“裸奔”完全没有被限流。这其实就是资源分配和资源隔离“不生效”的典型表现。要理解这个问题得先想明白 OceanBase 的资源管理逻辑——它分两层第一层是物理资源分配也就是把 CPU、内存、磁盘空间通过 unit 规格划分给不同的租户这层由 RootService 统一调度第二层是运行时资源隔离也就是通过 cgroup 或者 OceanBase 内部的租户工作线程限制把 CPU 使用上限、IO 权重等动态约束落实到具体的 SQL 执行上。OCP 只是这两层的“管理面板”它负责把配置写进内部表真正执行的是 OBServer 节点。所以“不生效”这个现象本质上就是两层链路中某一环断了。我排查下来最常见的原因是OCP 下发的配置没有同步到 OBServer 的运行时参数或者系统租户下修改限制的语法/参数作用域不对再或者就是cgroup 路径没挂对。下面我把整个排查和修复过程完整拆开你照着这个思路走大概率能直接定位到自己的问题。3. 核心概念OCP 资源分配与资源隔离的关系3.1 资源分配unit 规格是租户的“房子”在 OceanBase 里租户不直接绑定物理机器资源而是绑定一个逻辑单元叫UNIT资源单元。你可以把 unit 想象成给租户划的一间“房子”房子的面积内存上限、房间里的电器功率CPU 上限、储物空间磁盘空间都是在资源池里预先定义的。OCP 上创建租户时会让你选资源池规格背后就是生成一套 unit config。比如一个 unit 规格写的是CPU 8核、内存 32G、磁盘 100G那这个租户在任意一台 OBServer 上能占用的最大资源就是这个值。这个分配是“静态”的RootService 在租户创建和迁移时会根据 unit 规格做调度决策。资源分配不生效通常不是 unit 本身的问题而是 OCP 创建租户时没有把 unit 规格真正绑定到租户上或者资源池的unit_num设置不对导致租户在某些节点上没有分到实际的 unit。我在后面排查步骤里会专门提到怎么看这个。3.2 资源隔离cgroup 与租户工作线程限制资源隔离则是“动态”的。当多个租户在同一台 OBServer 上共存时必须保证任何一个租户的突发负载不会挤垮其他租户。OceanBase 的资源隔离主要分三层CPU 隔离通过 cgroup 的cpu.cfs_quota_us和cpu.cfs_period_us控制 CPU 使用上限同时可配置cpu_weight权重。内存隔离通过memory_limit和租户级内存配置限制内存占用。IO 隔离通过io_control相关配置限制租户的磁盘 IOPS 和带宽。OCP 的“资源隔离”页面实际上就是在帮你在系统租户下执行ALTER SYSTEM命令把这些限制写入__all_tenant等内部表。真正的生效依赖 OBServer 加载这些配置并施加到操作系统的 cgroup 上。3.3 两者关系先分配后隔离所以逻辑顺序是先有unit把资源“分”给租户数量级上的上限保障再有 cgroup/限流规则把资源“管”起来应对瞬时争抢。如果 unit 分配没生效那么隔离配置即使生效也是无源之水如果 unit 分配没问题但隔离没生效那就表现为资源被占满但配置看起来都对。我这个案例里其实 unit 分配是正常的问题出在隔离层。但为了让排查思路完整下面两个部分都会覆盖。4. 确认资源分配是否真的生效4.1 查看租户 unit 分布不要只信 OCP 界面上的展示直接用命令行确认。用 root 用户登录到 OceanBase 的 sys 租户执行SELECT t.tenant_id, t.tenant_name, rs.unit_id, u.unit_config_name, u.max_cpu, u.min_cpu, u.memory_size / 1024 / 1024 / 1024 AS mem_gb, rs.svr_ip, rs.svr_port FROM oceanbase.__all_tenant AS t JOIN oceanbase.__all_resource_unit AS u ON t.tenant_id u.tenant_id JOIN oceanbase.__all_resource_pool AS p ON t.tenant_id p.tenant_id JOIN oceanbase.__all_rs_pool AS rs ON p.resource_pool_id rs.resource_pool_id WHERE t.tenant_id 1000 ORDER BY t.tenant_id, rs.svr_ip;这条 SQL 能直接列出每个业务租户在每个节点上的 unit 分布情况包括 unit 配置名、CPU、内存规格。重点看两个点每个租户是否在每个预期的节点上都有 unit如果没有说明unit_num小于集群节点数租户在某些节点上拿不到资源但这不一定是“不生效”只是分布不均。max_cpu和min_cpu是否一致如果 OCP 配置的是 CPU 绑核即min_cpu max_cpu那这里应该显示相同值如果显示 0 或者异常小说明 unit 规格根本没落库。4.2 验证资源隔离配置是否落库然后是检查隔离配置。同样在 sys 租户下执行SELECT * FROM oceanbase.__all_tenant_resource_limit WHERE tenant_id 你的租户ID;看limit_type和limit_value字段。常见配置项包括cpu_quotaCPU 上限。cpu_weightCPU 权重。io_quotaIO 上限。memory_low/memory_high内存上下限。如果这里查出来是空表或者值和你 OCP 界面配置的不一致那说明 OCP 下发链路有问题或者你是在 OCP 里配了但没落到 sys 租户的资源限制表里。这是“隔离不生效”最常见的根源之一。4.3 直接查询 OBServer 上的 cgroup 状态如果内部表都正确那么就要看操作系统层是否真的创建了对应的 cgroup 目录。每台 OBServer 上查看ls /sys/fs/cgroup/cpu/oceanbase/正常情况下会有以租户 ID 命名的子目录比如tenant_1001。进去看cpu.cfs_quota_us和cpu.cfs_period_uscat /sys/fs/cgroup/cpu/oceanbase/tenant_1001/cpu.cfs_quota_us cat /sys/fs/cgroup/cpu/oceanbase/tenant_1001/cpu.cfs_period_us如果目录不存在或者 quota 值没有按照配置写入那就说明 OBServer 的 cgroup 挂载路径有问题或者操作系统没有使能 cgroup 相关支持。注意OceanBase 在 Linux 上依赖 cgroup v1。如果你的系统默认挂载的是 cgroup v2比如新版本 CentOS/RHEL 默认需要检查是否额外挂载了 v1 路径。这是一个非常隐蔽的坑后面我会详细说。5. 资源隔离不生效的排查与修复5.1 第一步确认 cgroup 是否挂载正确这个问题我踩过最大的坑就在这里。OceanBase 安装时需要确保 cgroup 文件系统挂载到/sys/fs/cgroup下。可以用mount | grep cgroup查看mount | grep cgroup正常情况下应该看到类似这样的输出cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,namesystemd) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu) cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) ...关键点是cpu 和 cpuacct 必须已经挂载。如果只有namesystemd之类的 v2 挂载而没有独立的 cpu、memory 等 v1 控制器目录OBServer 就无法在/sys/fs/cgroup/cpu/oceanbase/下创建租户目录隔离自然不生效。修复方式基于常见实践补充编辑/etc/fstab为 cgroup v1 控制器添加挂载项。执行mount -a或者逐个挂载mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu mount -t cgroup -o memory none /sys/fs/cgroup/memory mount -t cgroup -o blkio none /sys/fs/cgroup/blkio挂载完成后重启 OBServer再观察 cgroup 目录是否生成。5.2 第二步检查系统租户下资源隔离配置命令是否正确OCP 上的“资源隔离”界面在后台其实是通过 sys 租户执行ALTER SYSTEM语句。常见语法是ALTER SYSTEM SET cpu_quota 80 TENANT your_tenant;或者设置权重ALTER SYSTEM SET cpu_weight 80 TENANT your_tenant;注意这里的值是一个百分比还是具体核数取决于 OceanBase 版本配置语义。以 4.x 版本为例cpu_quota的 100 表示单核80 表示 0.8 核。很多人在 OCP 界面上把“90%”理解成 90 核结果配出来的值小得离谱导致实际限流阈值远高于预期——看起来“不生效”其实是生效了但阈值设置错了。另外IO 隔离配置也容易踩坑ALTER SYSTEM SET io_control weight100 TENANT your_tenant;如果 OCP 界面配置了 IO 隔离但不生效大概率是这个值没落库。直接查oceanbase.__all_tenant_resource_limitSELECT * FROM oceanbase.__all_tenant_resource_limit;确认是否有对应租户的记录。没有的话手动执行上面的ALTER SYSTEM语句看是否报错。如果报错根据报错信息定位——常见报错是“配置项不存在”或者“参数值超出范围”。5.3 第三步确认 OBServer 配置项是否开启资源限制OBServer 有两个关键配置项控制资源隔离的总开关enable_cgroup是否启用 cgroup默认可能是 false。resource_hard_limit租户资源硬上限默认 100表示可以超卖到物理资源的百分比。在 sys 租户下执行SHOW PARAMETERS LIKE enable_cgroup; SHOW PARAMETERS LIKE resource_hard_limit;如果enable_cgroup是 false那么即使前面 cgroup 挂载都没问题隔离也不会生效。需要修改ALTER SYSTEM SET enable_cgroup true;修改后观察 OBServer 日志observer.log中是否有 cgroup 初始化相关的警告或错误。常见报错包括“cgroup mount point not found”或者“cannot create cgroup directory”这些都是指向挂载路径的问题回到 5.1 去检查。5.4 第四步检查 IO 隔离是否依赖硬件/文件系统特性IO 隔离是另一个“看起来配了但没生效”的高发区。OceanBase 的 IO 隔离依赖blkiocgroup 控制器同时要求 OBServer 的数据目录所在文件系统支持io_control特性。某些云盘、某些内核版本下blkio 限流无法生效。排查方式确认 cgroup blkio 目录存在ls /sys/fs/cgroup/blkio/查看 blkio 目录下是否有oceanbase子目录以及租户的子目录。如果没有说明 OBServer 没有创建 blkio cgroup。可以在 OBServer 配置中检查data_dir所在设备的挂载选项。某些场景下即使 cgroup 目录创建了但 IOPS 限制无法精确生效是因为文件系统配合问题。这里常见的解决思路是改用io_weight替代绝对限流或者在 OCP 上对 IO 隔离的“优先级”字段做调整而不是直接设置硬上限。实测下来权重模式下即使不能精确到每个 IOPS至少能保证高优先级租户的延迟不会被打爆。5.5 第五步用压测验证修复效果配置改完后别急着下结论一定要用真实的查询压一下。我的做法是起两个会话会话 A在目标租户上跑一个大查询比如全表扫描或者排序。会话 B在另一个租户上跑同样的大查询或者跑一个高频的小查询观察延迟。同时观察top -p OBServer_PID看 CPU 占用是否被限制在配置值附近。比如你把租户 A 的 cpu_quota 配成 1 核那么压测时该租户所有 SQL 的 CPU 总占用应该稳定在 100% 左右一个核而不是跑到四五百。IO 方面用iostat或者 OceanBase 的GV$OB_TENANT_IO_STAT视图来确认 IOPS 是否在限流范围内。如果 CPU 限制生效但 IO 不生效问题基本可以锁定在 blkio 路径如果两个都不生效先回到enable_cgroup和系统 cgroup 挂载层面。6. 实操过程一次完整的修复实录下面用我实际处理的这个案例串一遍从发现问题到验证修复的完整过程方便你对照操作。6.1 环境信息OceanBase 版本4.2.1OCP 版本4.2.x操作系统CentOS 7.9内核 3.10.0集群共 3 台 OBServer业务租户 A 和租户 B 分布在集群内。隔离配置在 OCP 上已设置但业务反馈互不隔离。6.2 排查步骤实录第一步登录 sys 租户查询资源隔离配置落库情况SELECT * FROM oceanbase.__all_tenant_resource_limit WHERE tenant_id 1002;查询结果为空。接着查看系统配置项SHOW PARAMETERS LIKE enable_cgroup;结果显示enable_cgroup false。到这里问题的直接原因已经浮出水面——OCP 界面上配的隔离项实际上没有把总开关打开。第二步手动开启并配置ALTER SYSTEM SET enable_cgroup true;再查询确认SHOW PARAMETERS LIKE enable_cgroup;显示为true。第三步重新在 OCP 上调整资源隔离参数或者手动执行ALTER SYSTEM SET cpu_quota 200 TENANT tenant_a; ALTER SYSTEM SET cpu_weight 50 TENANT tenant_a; ALTER SYSTEM SET io_control weight50 TENANT tenant_a;再次查询__all_tenant_resource_limit发现记录已经写入。第四步检查 OBServer 节点的 cgroup 目录ls /sys/fs/cgroup/cpu/oceanbase/发现目录为空OBServer 尚未自动创建租户 cgroup。查看 OBServer 日志grep -i cgroup /home/admin/oceanbase/log/observer.log | tail -20日志中没有明显报错。重启该 OBServer 后再次查看ls /sys/fs/cgroup/cpu/oceanbase/出现了tenant_1002目录。这一步印证了部分配置项需要重启才能完全生效OCP 上如果只推送了配置没有重启某些版本下 cgroup 目录不会立即创建。第五步验证隔离是否真的生效。在租户 A 上发起一个大查询同时观察 CPUtop -p $(pgrep -f observer | head -1)观察 CPU 占用租户 A 被限制在 200%2 核附近不再像之前那样跑到 600% 以上。租户 B 的延迟恢复正常。6.3 过程中踩过的细节坑如果 OCP 版本较老配置下发接口和ALTER SYSTEM语法存在兼容性问题会出现 OCP 界面显示“配置成功”但内部表没更新的情况。这时候不要只在界面上反复保存直接到 sys 租户用命令行验证。命令行是最终的事实来源。修改enable_cgroup后不建议热加载配置项完事。稳妥做法是维护窗口内重启 OBServer否则部分节点 cgroup 目录长时间不创建你会误判成“没生效”。如果集群是多节点确认所有 OBServer 节点的 cgroup 目录都出现了。有些节点因为挂载路径不同可能只有部分节点生效那表现为“同一个租户在不同节点上资源上限不一致”。7. 常见问题速查表与注意事项现象可能原因排查命令 / 操作OCP 配置了隔离但完全不生效enable_cgroup为 falseSHOW PARAMETERS LIKE enable_cgroup;然后设为 trueCPU 隔离不生效cgroup v1 未挂载或只挂了 v2mount | grep cgroup补充挂载 cpu、cpuacctIO 隔离不生效blkio 未挂载或文件系统不支持ls /sys/fs/cgroup/blkio/确认目录存在CPU 隔离部分生效某些节点生效部分 OBServer 没有重启或者挂载路径不一致逐台检查/sys/fs/cgroup/cpu/oceanbase/配置落库了但值不对OCP 界面的百分比和内部值语义不同用SELECT * FROM oceanbase.__all_tenant_resource_limit比对实际值内存隔离不生效租户内存上下限设置不合理检查memory_low/memory_high是否大于 unit 规格的一半OCP 点击配置后内部表无记录版本兼容问题或未真正保存直接 sys 租户执行ALTER SYSTEM8. 一些实操心得资源分配和隔离的问题排查顺序很重要。我的习惯是先看unit 分配再看隔离配置落库最后看cgroup 层面这个顺序不要乱。因为 unit 分配如果本身有问题隔离配置再正确底层的资源上限也是不对的。还有一个容易让人困惑的点是OCP 界面上的“资源隔离”和 OceanBase 内核里的“资源隔离”并不是完全对应的。OCP 侧重于配置展示和下发而真正扛压的是内核中的 cgroup 和工作线程调度逻辑。所以任何配置变更后都要经过一次真实的压测验证不要盲目相信界面状态。另外OCP 的版本和 OceanBase 的版本要尽量保持在一个兼容矩阵内。旧版 OCP 配新版 OceanBase或者反过来配置下发偶发失败是很常见的。升级 OCP 到较新版本往往能解决很多“配置不生效”的隐性问题。最后IO 隔离这块如果一个业务场景是高优先级租户需要稳定低延迟建议用IO weight权重而不是绝对限流。权重策略在共享存储上表现更稳定也不会因为峰值流量波动导致误伤。具体权重值可以从 100 开始调观察高优先级租户的大查询执行时间是否明显缩短。如果你现在也遇到资源隔离不生效别慌按这个思路走查落库、开总开关、看挂载、压测验证。大概率能在半小时内定位到根因。