基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。
缩小租户规格时遇到报错 requested memory over 90% 的原因和解决方法
更新时间:2026-07-02 15:41
问题描述
通过 OCP Web 界面缩小租户规格时,在 Alter resource pool unit spec 这一步遇到报错 requested memory over 90 percent of total available memory not supported。
原租户规格: 90C/400G,期望将租户规格调小至 3C/12G。

日志信息如下。
2024-02-05 16:18:13.961 INFO 8 --- [pool-manual-subtask-executor16,9c46eeb151a54ad4,1682f9101db2] c.o.ocp.obsdk.connector.ConnectTemplate : [obsdk] sql: ALTER RESOURCE POOL `pool_perforacle_zone1_xxxx` UNIT = ?, args: [config_perforacle_zone1_Unit_xxxxx]
2024-02-05 16:18:14.029 WARN 8 --- [pool-manual-subtask-executor16,9c46eeb151a54ad4,1682f9101db2] c.o.ocp.obsdk.connector.ConnectTemplate : [obsdk] update failed, sql:[ALTER RESOURCE POOL `pool_perforacle_zone1_xxxx` UNIT = ?], error message:[PreparedStatementCallback; SQL [ALTER RESOURCE POOL `pool_perforacle_zone1_xxxx` UNIT = ?]; (conn=1050330) requested memory over 90 percent of total available memory not supported; nested exception is java.sql.SQLFeatureNotSupportedException: (conn=1050330) requested memory over 90 percent of total available memory not supported]
2024-02-05 16:18:14.141 INFO 8 --- [pool-manual-subtask-executor16,9c46eeb151a54ad4,1682f9101db2] c.o.ocp.obsdk.connector.ConnectTemplate : Last Trace Info:[YB42AC140F01-0006109C1E515ACF-0-0]
2024-02-05 16:18:14.204 ERROR 8 --- [pool-manual-subtask-executor16,9c46eeb151a54ad4,1682f9101db2] c.o.o.c.t.e.c.w.subtask.SubtaskExecutor : requested memory over 90 percent of total available memory not supported
java.sql.SQLException: requested memory over 90 percent of total available memory not supported
at com.oceanbase.jdbc.internal.protocol.AbstractQueryProtocol.readErrorPacket(AbstractQueryProtocol.java:2192)
at com.oceanbase.jdbc.internal.protocol.AbstractQueryProtocol.readPacket(AbstractQueryProtocol.java:2057)
at com.oceanbase.jdbc.internal.protocol.AbstractQueryProtocol.getResult(AbstractQueryProtocol.java:1951)
at com.oceanbase.jdbc.internal.protocol.AbstractQueryProtocol.executeQuery(AbstractQueryProtocol.java:370)
at com.oceanbase.jdbc.JDBC4PreparedStatement.executeInternal(JDBC4PreparedStatement.java:234)
at com.oceanbase.jdbc.JDBC4PreparedStatement.execute(JDBC4PreparedStatement.java:161)
at com.oceanbase.jdbc.JDBC4PreparedStatement.executeUpdate(JDBC4PreparedStatement.java:195)
at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeUpdate(DruidPooledPreparedStatement.java:255)
at org.springframework.jdbc.core.JdbcTemplate.lambda$update$2(JdbcTemplate.java:973)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:656)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:968)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1023)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1033)
at com.oceanbase.ocp.obsdk.connector.ConnectTemplate.updateInner(ConnectTemplate.java:294)
at com.oceanbase.ocp.obsdk.connector.ConnectTemplate.update(ConnectTemplate.java:265)
at com.oceanbase.ocp.obsdk.operator.resource.MysqlResourceOperator.modifyResourcePoolUnitConfig(MysqlResourceOperator.java:315)
at com.oceanbase.ocp.obops.internal.tenant.ResourcePoolServiceImpl.baseModifyResourcePool(ResourcePoolServiceImpl.java:416)
at com.oceanbase.ocp.obops.internal.tenant.ResourcePoolServiceImpl.modifyResourcePool(Re
sourcePoolServiceImpl.java:384)
at com.oceanbase.ocp.obops.internal.tenant.task.AlterResourcePoolUnitSpecTask.run(AlterResourcePoolUnitSpecTask.java:44)
at com.oceanbase.ocp.core.task.engine.runner.JavaSubtaskRunner.execute(JavaSubtaskRunner.java:64)
at com.oceanbase.ocp.core.task.engine.runner.JavaSubtaskRunner.doRun(JavaSubtaskRunner.java:32)
at com.oceanbase.ocp.core.task.engine.runner.JavaSubtaskRunner.run(JavaSubtaskRunner.java:26)
at com.oceanbase.ocp.core.task.engine.runner.RunnerFactory.doRun(RunnerFactory.java:76)
at com.oceanbase.ocp.core.task.engine.coordinator.worker.subtask.SubtaskExecutor.doRun(SubtaskExecutor.java:203)
at com.oceanbase.ocp.core.task.engine.coordinator.worker.subtask.SubtaskExecutor.redirectConsoleOutput(SubtaskExecutor.java:197)
at com.oceanbase.ocp.core.task.engine.coordinator.worker.subtask.SubtaskExecutor.lambda$submit$2(SubtaskExecutor.java:134)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
问题原因
RootService 模块在调整租户规格前需要先检查一下:调整后的租户规格的 MemStore 能否安全容纳租户当前正在使用中的 MemStore 数据,如果无法安全容纳租户当前 MemStore 中的数据,则 RootService 模块会拒绝本次修改,并返回用户一个报错 [errcode=-4007] requested memory over 90 percent of total available memory not supported。
具体计算公式如下。
缩容后最大允许安全使用的MemStore 内存大小 = 租户当前的 memstore_limit * 缩容的比例(即 new_memory_size/old_memory_size)* 0.9。
以上面的报错环境为例。
租户当前的 memstore_limit = 180GB,因此缩容后最大允许安全使用的 MemStore 内存大小 = 180GB * (12G / 400G) * 0.9 = 4.86GB。
结合当时的 rootservice.log 中的报错日志信息如下。
[2024-02-05 14:08:49.758559] WDIAG [RS] check_shrink_memory (ob_unit_manager.cpp:7790) [1654312][DDLQueueTh0][T0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=13][errcode=-4007] new memory will cause memory use percentage over ninety percentage(mem_info={tenant_id:1002, server:"xxx.xxx.xxx.xxx:2882", active_memstore_used:18463326208, total_memstore_used:18463326208, major_freeze_trigger:39728484348, memstore_limit:193273528300}, old_memory=429496729600, new_memory=12884901888, max_used_ratio=9.000000000000000222e-01, max_used_memory=5218385264, ret=-4007)
这边日志中的 total_memstore_used 代表当前 MemStore 中的数据实际占用的 MemStore 内存的大小;max_used_memory 代表如果缩容后最大允许占用的 MemStore 内存大小,即上述公式中的缩容后最大允许安全使用的 MemStore 内存大小。
因为 max_used_memory = 4.86GB < total_memstore_used=17.2GB,所以在缩小租户规格时失败。
适用版本
OceanBase 数据库 V4.0.0 及之后的版本。
OCP V4.0.0 及之后的版本。
解决方法
执行租户合并释放内存后,再尝试缩容。
如果合并结束后再次缩容仍然失败,应该是因为该租户当前存储的 Tablet 数据较多,导致需要加载使用的 MemStore 内存较大,可以尝试删除部分过期用户数据后再执行合并操作或者直接改大租户缩容的目标规格。