Understanding LOG_DISK Resource Limits and Tenant Memory Allocation in OceanBase

Background : A client configured a relatively small log disk (about 1.5 times the cluster memory) and, while CPU and memory were sufficient, encountered the error "LOG_DISK resource not enough" when creating a tenant.

Environment Information :

Architecture: Single‑node cluster

Version: OceanBase 4.2.1.4

MySQL [oceanbase]> select svr_ip,status,build_version from __all_server;
+--------------+--------+-------------------------------------------------------------------------------------------+
| svr_ip       | status | build_version                                                                            |
+--------------+--------+-------------------------------------------------------------------------------------------+
| 10.186.64.61 | ACTIVE | 4.2.1.4_104010012024030714-c4f3400ad2839e337bc9dab5d1bfe1d01134a1d7(Mar  7 2024 14:32:22) |
+--------------+--------+-------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

Cluster resource overview (CPU, memory, log disk):

MEM_CAPACITY : Memory available to the observer process.

LOG_DISK_CAPACITY : Total log‑disk size, 41.8 GB.

LOG_DISK_ASSIGNED : Log‑disk already allocated, 6 GB.

Remaining assignable CPU: 18‑2 = 16 C.

Remaining assignable memory: 24‑2 = 22 GB.

MySQL [oceanbase]> SELECT SVR_IP, SVR_PORT , ZONE , SQL_PORT , CPU_CAPACITY , CPU_CAPACITY_MAX, CPU_ASSIGNED , CPU_ASSIGNED_MAX ,MEMORY_LIMIT/1024/1024/1024 MEMORY_LIMIT_GB , MEM_CAPACITY/1024/1024/1024 MEM_CAPACITY_GB, MEM_ASSIGNED/1024/1024/1024 MEM_ASSIGNED_GB ,LOG_DISK_CAPACITY/1024/1024/1024 LOG_DISK_CAPACITY_GB,LOG_DISK_ASSIGNED/1024/1024/1024 LOG_DISK_ASSIGNED_GB,LOG_DISK_IN_USE/1024/1024/1024 LOG_DISK_IN_USE_GB  FROM GV$OB_SERVERS;
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
| SVR_IP       | SVR_PORT | ZONE  | SQL_PORT | CPU_CAPACITY | CPU_CAPACITY_MAX | CPU_ASSIGNED | CPU_ASSIGNED_MAX | MEMORY_LIMIT_GB | MEM_CAPACITY_GB | MEM_ASSIGNED_GB | LOG_DISK_CAPACITY_GB | LOG_DISK_ASSIGNED_GB | LOG_DISK_IN_USE_GB |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
| 10.186.64.61|     2882 | zone1 |     2881 |           18 |               18 |           2 |                2 | 30.000000000000| 24.000000000000|  2.000000000000|      41.875000000000|       6.000000000000| 0.125000000000 |
+--------------+----------+-------+----------+--------------+------------------+--------------+------------------+-----------------+-----------------+-----------------+----------------------+----------------------+--------------------+
1 row in set (0.00 sec)

The sys tenant already occupies 2 C and 2 GB memory, leaving 16 C and 22 GB for other tenants.

Reproducing the Error

Creating a resource unit with 12 GB memory:

MySQL [oceanbase]> CREATE RESOURCE UNIT mem_test_unit MEMORY_SIZE = '12G',MAX_CPU = 4, MIN_CPU = 4;
Query OK, 0 rows affected (0.02 sec)

Attempting to create a resource pool using this unit triggers the error:

MySQL [oceanbase]> CREATE RESOURCE POOL pool_evan UNIT='mem_test_unit', UNIT_NUM=1, ZONE_LIST=('zone1');
ERROR 4733 (HY000): zone 'zone1' resource not enough to hold 1 unit. ... server "10.186.64.61:2882" LOG_DISK resource not enough

Key Questions

Why does creating a 4C12G pool fail when 16C22GB resources appear available?

What is the relationship between LOG_DISK size and tenant memory?

Log‑Disk Size vs. Tenant Memory

Creating a 1C1G tenant increases LOG_DISK_ASSIGNED_GB from 6 GB to 9 GB, showing that each 1 GB of memory consumes roughly 3 GB of log‑disk space.

MySQL [oceanbase]> CREATE RESOURCE UNIT unit_1g MEMORY_SIZE = '1G',MAX_CPU = 1, MIN_CPU = 1;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]> CREATE RESOURCE POOL pool_1g UNIT='unit_1g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)
MySQL [oceanbase]> CREATE TENANT IF NOT EXISTS tenant_1g PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool_1g') set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (26.05 sec)

After this tenant is created, LOG_DISK_ASSIGNED_GB becomes 9 GB, confirming a 1 GB‑memory‑to‑3 GB‑log‑disk ratio.

Deriving the Memory Upper Limit

Using the formula (LOG_DISK_CAPACITY_GB - LOG_DISK_ASSIGNED_GB) / 3 :

(41.875 GB - 6 GB) / 3 ≈ 11.96 GB , i.e., the cluster can safely allocate up to about 11 GB of additional memory.

Verification

After dropping the 1C1G tenant and its pool, the log‑disk usage returns to 6 GB. Creating a 16C11G tenant consumes the remaining log‑disk space, raising LOG_DISK_ASSIGNED_GB to 39 GB, which matches the calculated limit.

MySQL [oceanbase]> CREATE RESOURCE UNIT unit_11g MEMORY_SIZE = '11G',MAX_CPU = 16, MIN_CPU = 16;
Query OK, 0 rows affected (0.01 sec)
MySQL [oceanbase]> CREATE RESOURCE POOL pool_11g UNIT='unit_11g', UNIT_NUM=1, ZONE_LIST=('zone1');
Query OK, 0 rows affected (0.02 sec)
MySQL [oceanbase]> CREATE TENANT IF NOT EXISTS tenant_11g PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool_11g') set OB_TCP_INVITED_NODES='%';
Query OK, 0 rows affected (25.99 sec)

Answers to the Two Questions

Even though 16 C and 22 GB memory appear free, the log‑disk limit (≈11 GB usable memory) prevents allocating a 12 GB memory tenant, resulting in the LOG_DISK error.

The default LOG_DISK size is three times the tenant's memory specification (minimum 2 GB). Therefore, insufficient log‑disk capacity blocks memory allocation.

Recommendation

Configure the log‑disk size to be at least three (preferably four) times the maximum memory you plan to allocate for tenants, especially in production environments, to avoid resource‑insufficient errors.

References

GV$OB_SERVERS documentation: https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001051773

ALTER RESOURCE UNIT documentation: https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220301