做OceanBase运维的朋友在OCP上调整租户资源是家常便饭。但“配置不生效”这个问题我前前后后被问到过很多次控制台明明显示资源已从4C8G调成了16C32G业务侧也确认做过切换可数据库压测就是上不去更头疼的是一个租户跑大查询能把整台宿主机CPU吃满旁边其他租户毫无还手之力排障时查来查去发现资源隔离压根没有真正起作用。这两个问题表面上是OCP交互或展示问题实际上牵扯到OCP配置下发、Observer资源管理、操作系统cgroup等多个层面。这篇内容我就把资源分配和资源隔离不生效的排查思路完整拆开把验证手段和修复命令直接给出来正在被OceanBase租户资源问题缠住的DBA、运维和平台研发可以参考一下。1. 资源分配与隔离的完整链路先搞懂配置是怎么落地的1.1 从OCP界面到Observer内部一条配置的旅行先建立一个整体认知OCP上对租户做资源分配表面上是填几个数字、点一下保存背后至少要经历四个环节。OCP的元数据库保存新的资源规格配置。OCP生成对应的修改任务调用目标集群的标准SQL接口比如ALTER RESOURCE UNIT、ALTER RESOURCE POOL下发到集群。集群的RootService接受变更计算新Unit的分布位置并更新内部元数据。各节点上的Observer加载新的Unit配置按新规格为租户预留CPU和内存。任何一个环节出了问题都会出现OCP界面显示正常、实际不生效的情况。很多人一遇到问题就盯着OCP界面看但OCP只是一个管控面真正决定资源是否落地的是集群内部这套流程。所以排查的第一步是分清“OCP配置层面”和“集群运行层面”这在后续需要用内部视图反复验证。还有一个细节容易让人误判单位换算。OCP上看内存单位是GB内部视图里是字节CPU在界面上是整数内部有MIN_CPU和MAX_CPU两个值。看到数字对不上不要急着怀疑没生效先确认是否已经做过单位换算。1.2 cgroup是实现资源隔离的底层前提OceanBase的CPU资源隔离不是像虚拟机那样靠CPU pin而是依赖Linux cgroup的cpu子系统。原理并不复杂Observer启动时会尝试在cgroup的cpu目录下创建自己的子目录通常是/sys/fs/cgroup/cpu/oceanbase然后根据启动参数里的cpu_limit和租户的unit配置把对应的cpu.cfs_quota_us写入租户目录。Linux调度器看到quota之后就会限制这个cgroup里的线程最多只能占用多少CPU时间。这里有个关键点如果没有cgroup或者路径不可写Observer并不会报错并停下来它顶多打一条warning日志然后继续以不隔离的方式运行。这也是为什么很多环境里资源隔离不生效却一直没人发现。排查时一定要先确认系统层面是否满足条件而不是上来就怀疑OCP配置。检查cgroup基线条件通常看三件事挂载情况、目录路径、observer进程权限。后面第3章会具体展开命令。2. 资源分配不生效先查配置下发再查视图落地2.1 第一步检查OCP任务是否真正执行成功处理过OCP问题的朋友都知道OCP的任务列表是最容易被忽略的入口。界面上显示“变更成功”只代表OCP认为它向目标集群发送的指令执行成功不代表底层资源真的变了。也有一些情况是任务表面上成功但实际执行过程中已经产生了异常比如某个节点离线、磁盘空间不足任务会重试或中断。所以我会先让用户在OCP左上角的“任务管理”里把“租户变更”“资源变更”这类任务的执行历史打开看提交时间和执行状态。如果存在失败记录点进去看具体的fail信息常见的有Resource pool does not existNo enough resource to create unitTimeout这些说明问题出在集群侧而不是OCP侧。先把失败任务清掉或重跑再继续往下查。如果任务历史里压根没有对应记录说明OCP上的操作可能只是保存了配置没有触发真正的变更任务这时候去OCP的资源池页面重新点击“应用”或“提交”即可。2.2 第二步连接sys租户核对GV$OB_UNITS既然OCP有可能“撒谎”就要直接问集群要真相。用rootsys账号连到sys租户执行一条查询把所有租户在不同节点上的Unit实际分配情况拉出来SELECT unit_id, tenant_id, svr_ip, svr_port, max_cpu, min_cpu, ROUND(max_memory / 1024 / 1024 / 1024, 2) AS max_mem_gb, ROUND(min_memory / 1024 / 1024 / 1024, 2) AS min_mem_gb FROM oceanbase.GV$OB_UNITS ORDER BY tenant_id, svr_ip;这条SQL在3.x和4.x里基本通用。GV$OB_UNITS记录的是每个节点上真实创建的Unit实例。要注意这里的tenant_id是数字不是租户名可以通过下面的SQL对照出对应关系SELECT tenant_id, tenant_name FROM oceanbase.DBA_OB_TENANTS;排查时的核心判断逻辑如果GV$OB_UNITS里MAX_CPU、MAX_MEMORY已经是OCP上配置的目标值但业务侧还是感觉没变说明资源确实已经下发问题可能出在业务连接、并发负载或者SQL本身而不是资源分配。如果GV$OB_UNITS里的值和OCP上的目标值不一致说明配置没有真正落到集群继续看Unit规格名称和资源池引用关系。我遇到过一个很有意思的情况OCP界面上显示8C16G结果是8C是按MAX_CPU算的16G是按内存总量算的但执行压测时发现CPU只能用到2C。后来确认是MIN_CPU还是旧值而某些场景下调度器会按MIN_CPU执行。所以查询时一定把MAX和MIN都拉出来看别只关注MAX。2.3 第三步排查资源池与Unit规格之间的关系资源分配不生效我遇到的最常见原因就是OCP上改了Unit规格但没有把它重新挂到资源池上。OceanBase的分配模型是租户 - 资源池 - Unit规格。租户本身不直接关心CPU和内存它只知道自己绑定了一个资源池。真正定义CPU、内存大小的是Unit规格资源池通过UNIT_CONFIG_ID引用规格。如果只是新建了一个16C的Unit规格而资源池还指向旧的4C规格租户拿到的当然还是4C。查看资源池和Unit规格的关联关系SELECT pool.name AS pool_name, pool.tenant_id, cfg.unit_config_id, cfg.name AS unit_config_name, cfg.max_cpu, cfg.min_cpu, ROUND(cfg.memory_size / 1024 / 1024 / 1024, 2) AS mem_gb FROM oceanbase.DBA_OB_RESOURCE_POOLS pool LEFT JOIN oceanbase.DBA_OB_UNIT_CONFIGS cfg ON pool.unit_config_id cfg.unit_config_id;如果发现资源池引用的UNIT_CONFIG里CPU还是老值就需要在OCP上找到该资源池操作“变更Unit配置”或者直接在sys租户下执行ALTER RESOURCE POOL pool_name UNIT u16c;注意这里操作的是资源池的引用不是单纯修改Unit规格本身。很多人改了规格不重新挂载这是核心误区。另外一个资源池分布在多个Zone每个Zone下面各有一个Unit实例执行变更后要确认每个Zone的Unit都刷新了别只改了某一个Zone。3. 资源隔离不生效CPU、内存逐个击破3.1 CPU隔离不生效的排查清单如果GV$OB_UNITS显示CPU已经分配到位但多个租户挤在同一台机器上还是互相影响大概率是资源隔离层面没生效。这里按顺序检查四件事。第一件看全局参数SHOW PARAMETERS LIKE enable_cgroup;这个参数必须为True。在4.x里OCP安装或手工配置时如果用的是默认模板这个参数往往没有打开。设置为True后还需要注意很多版本重启observer后才会真正生效所以改完不要不管。第二件看observer的cgroup目录是否创建ls -l /sys/fs/cgroup/cpu/正常情况下应该能看到oceanbase目录在这个目录下一个租户一个子目录命名通常带租户ID。如果根本没有oceanbase目录说明cgroup挂载正常但observer没有成功写入继续检查observer日志grep -i cgroup store/log/observer.log常见关键字是cgroup相关的warning比如权限拒绝或路径不存在。第三件确认挂载路径。很多物理机上cgroup的cpu子系统路径是/sys/fs/cgroup/cpu有些发行版是/sys/fs/cgroup/cpu,cpuacct还有些系统挂在/sys/fs/cgroup/cpu/。路径不对时observer会回退到非隔离模式。手动查看挂载情况mount | grep cgroup如果没有cpu子系统需要先挂载mkdir -p /sys/fs/cgroup/cpu mount -t cgroup -o cpu cpu /sys/fs/cgroup/cpu如果是容器化部署需要在宿主机层面确保cgroup已经挂到容器里容器内的observer才能写入。这个细节经常被忽略容器场景下单看容器内目录会排查半天。第四件确认observer进程的PID是否真的落到了对应cgroup目录的tasks或cgroup.procs文件中cat /sys/fs/cgroup/cpu/oceanbase/tenant_dir/cgroup.procs | head如果这个文件是空的说明observer进程根本没有加入cgroup组隔离自然不生效。这种情况多半和启动顺序有关cgroup目录创建时observer主进程还没就绪重启observer基本能解决。3.2 内存隔离不生效的排查思路内存隔离的情况比CPU稍微简单一点但有一个特点内存是硬隔离一旦达到上限新分配内存会失败或者触发内存合并所以业务表现为异常而不是“资源没分配”。如果怀疑内存隔离没生效先看unit里的memory是否已经分配到租户。GV$OB_UNITS里的MAX_MEMORY是硬上限这个值由unit配置的MEMORY_SIZE决定。对照OCP的显示值确认单位是否一致。真正容易踩的坑是给租户分配的unit内存在observer进程总内存中并没有被真正预留。OceanBase的observer进程会通过memory_limit_percentage参数算出自己的总内存池再按照各租户unit的memory size进行比例分配。如果总内存池本身就很小或者设置了system_memory、memory_limit这些老参数租户实际可用的内存会在内部被进一步限制但GV$OB_UNITS里显示的MAX_MEMORY却不受影响。所以排查内存问题时不仅要看unit还要看observer级参数SHOW PARAMETERS LIKE memory_limit_percentage; SHOW PARAMETERS LIKE system_memory; SHOW PARAMETERS LIKE memory_limit;我的经验是优先使用memory_limit_percentage来控制总内存池而不是直接把memory_limit写死后者在老版本中容易跟memstore内存参数产生冲突。如果发现租户内存上限一直没有变化多半是OCP里调整unit内存后资源池没有重新指向处理方法同上一章的ALTER RESOURCE POOL。还有一个表现容易混淆租户内存使用率长期徘徊在高位但业务没报错。这种情况可能不是隔离不生效而是租户的内存上限已经生效block cache和memstore在抢内存导致淘汰频繁。先看缓存命中率和memstore内存水位别一上来就调大unit。3.3 压测验证隔离效果的方法配置改完不能只看视图建议做一次实际压测。以CPU隔离为例。在租户A用一个耗CPU的并行查询把CPU跑满比如循环做笛卡尔积聚合。在宿主机上同时用top观察observer进程的CPU占用以及us和sy占比。到cgroup目录下读取配额cat /sys/fs/cgroup/cpu/oceanbase/tenant_dir/cpu.cfs_quota_us cat /sys/fs/cgroup/cpu/oceanbase/tenant_dir/cpu.cfs_period_usquota和period的比值就是该租户能被分到的CPU核数上限。比如period是100000100msquota是1600000对应16核。如果这个比值和你配置的MAX_CPU一致说明隔离已经在起作用。如果压测时进程CPU占用远超这个比例继续检查目录里的进程PID是否写全以及线程是否在正确的cgroup下。内存隔离的验证可以看租户内存使用是否在接近上限时出现写入阻塞或性能断崖同时查看memstore告警。这个验证比较伤业务建议先在测试环境做生产环境压测前一定要评估风险。4. 一个真实案例从界面到视图的完整定位过程4.1 问题现象与初步判断我处理过的一个客户环境比较典型。OceanBase 4.2.1集群三台物理机每台机器64核。OCP上给租户A调整到16C租户B也调整到16C并开启了CPU资源隔离。结果业务上线后租户A的一个大查询能把整台宿主机CPU占满租户B的TP业务立刻变慢。租户A自己的压测又发现最多只能用4C再多加并发也是4C附近封顶。客户判断是资源分配和资源隔离都失效了。初步判断分配不生效和隔离不生效同时存在。因为如果分配生效租户A应该能用到16C如果隔离生效它不可能把宿主机占满。两种症状叠加说明unit配置或cgroup机制可能有多个问题。4.2 逐层排查并定位根因我先在OCP看租户的资源概览界面上确实显示租户A是16C但OCP这块只显示“当前规格”看不到每个节点上的Unit实例。接着连到sys租户执行GV$OB_UNITS查询SELECT unit_id, tenant_id, svr_ip, max_cpu, min_cpu, max_memory FROM oceanbase.GV$OB_UNITS WHERE tenant_id 1001;结果发现租户A在所有三个节点的MAX_CPU都是4。到这里已经确定OCP界面只是“预期规格”集群实际Unit没有跟着变。继续查资源池引用关系DBA_OB_RESOURCE_POOLS里的UNIT_CONFIG_ID指向的还是一个名为u4c的旧Unit规格。OCP上新建了一个名为u16c的Unit规格但资源池没有重新指向。根因初步定位资源池引用未更新。第二个问题单独查。GV$OB_UNITS显示4C对应的Unit创建是正常的再看enable_cgroup参数值是False系统cgroup目录下也没有oceanbase目录。所以隔离不生效的原因是功能压根没有开启。4.3 执行修复操作与最终验证修复分两步。第一步处理分配在sys租户执行ALTER RESOURCE POOL pool_a UNIT u16c; ALTER RESOURCE POOL pool_b UNIT u16c;如果执行失败提示资源不足需要确认三台机器上剩余CPU是否足够OceanBase的Unit调度还会考虑zone内均衡。资源不足时有几种选择调低其他租户规格或者新增节点后把Unit迁移过去。第二步处理隔离打开cgroup功能ALTER SYSTEM SET enable_cgroup True;这个参数是集群级boolean参数设置后建议逐台重启observer让cgroup目录创建流程完整跑一遍。重启前确认操作系统已经挂载cpu子系统否则重启完照样不生效。重启顺序建议从follower节点开始最后切主避免长时间没有leader。验证时先看视图SELECT unit_id, tenant_id, max_cpu, max_memory FROM oceanbase.GV$OB_UNITS WHERE tenant_id IN (1001, 1002);再压测租户A能把CPU打到16C附近同步观察cgroup目录下cpu.cfs_quota_us的数字确认配额已经写入。同时跑租户B的交易整个宿主机CPU不会被打爆各租户按照配额公平分片。客户实际观察后租户A压测峰值CPU稳定在15.8C左右租户B的TP响应恢复正常问题处理完毕。5. 避坑指南与常见问题速查表5.1 关于OCP版本与OceanBase版本的关键提醒处理资源问题时版本差异是一个非常大的坑。3.x和4.x在参数名、视图名、系统约束上都有变化OCP版本与集群版本也需要兼容。如果拿3.x的文档去查4.x的视图会找不到表导致误判成“资源没生效”。比如DBA_OB_UNIT_CONFIGS这类视图在4.x才规范化3.x里更多是__all_virtual_xxx形式。开始排查前先确认版本别让版本因素干扰判断。OCP本身也有版本概念如果OCP版本和OceanBase集群版本跨度太大可能出现OCP下发命令所用语法与集群不匹配导致任务执行失败。这类失败通常在OCP任务详情里有明确报错看不明白时先搜一下对应版本的语法变更记录。5.2 资源分配和隔离排查速查表现象可能原因处理建议OCP显示已变更GV$OB_UNITS还是旧值OCP任务未成功下发或资源池未重新指向Unit规格看任务管理检查资源池引用执行ALTER RESOURCE POOL改了Unit规格租户规格没变改的是规格定义没有改资源池引用确认DBA_OB_RESOURCE_POOLS的UNIT_CONFIG_ID是目标规格部分节点生效部分节点不生效资源池跨多个Zone部分Zone的Unit未刷新检查每个Zone的Unit必要时手动触发Unit迁移enable_cgroupTrue仍不隔离CPUobserver重启过但其没权限写cgroup目录检查目录权限确认observer进程属主重启observercgroup目录下没有oceanbase目录操作系统未挂载cpu子系统或observer未创建mount检查手动挂载后重启observer内存上限看起来对业务还是超限抛错检查memory_limit_percentage和system_memory用百分比方式控制总内存池避免参数冲突多个租户同时跑CPU互相抢占租户线程不在正确的cgroup下检查cgroup.procs文件内容确认PID归属这张表是我自己在排障时最常对照的。实际工作中很多问题不是单一原因可能像案例里那样分配和隔离同时出问题排查时不要只把头绪放在一个方向上。根据我个人经验OCP上的“配置成功”更像是一张意向单真正决定资源状态的是底层视图和操作系统状态。每次改完资源先跑一遍GV$OB_UNITS查询确认分配再检查cgroup目录确认隔离这两个动作加起来不超过五分钟但能省掉后面一整天的业务投诉。另外动cgroup相关配置前一定要记得评估重启observer的影响能安排在维护窗口就不要在业务高峰期强上。
