Overview of resource isolation

This topic describes the concepts, methods, and application scenarios of resource isolation.

Control groups (cgroups) are a mechanism provided by the Linux kernel that groups (or partitions) a set of system tasks and their child tasks into different resource-level groups based on specific behavior, thereby providing a unified framework for system resource management.

In the current version of OceanBase Database, tenant worker threads and most background threads are tenant-specific, while network threads are shared. Therefore, after configuring the cgroup directory, administrators can use the DBMS_RESOURCE_MANAGER system package to control the CPU and IOPS usage of tenants.

DBMS_RESOURCE_MANAGER package

In OceanBase Database, resource allocation in the database is managed through the DBMS_RESOURCE_MANAGER PL system package, thereby achieving resource isolation. The DBMS_RESOURCE_MANAGER system package is primarily used to maintain the following elements:

• Resource group: A group of sessions that are combined based on resource requirements. The system allocates resources to a resource group rather than to individual sessions.

• Resource management plan: A container for resource management plan content, specifying how resources are allocated to resource groups. You can control resource allocation by activating a specific resource management plan. A resource management plan can contain multiple resource management plan contents, but it cannot contain two identical ones.

• Resource management plan content: Used to associate a resource group with a resource management plan and specify how resources are allocated to that resource group.

For more information about the DBMS_RESOURCE_MANAGER system package, see DBMS_RESOURCE_MANAGER system package (Oracle-compatible mode) and the DBMS_RESOURCE_MANAGER system package (MySQL-compatible mode).

Resource isolation methods

When configuring resource isolation within a tenant using the DBMS_RESOURCE_MANAGER system package, the granularity of resource isolation can be categorized into the following types:

• User-level resource isolation

  User-level resource isolation is achieved by specifying the mapping between users and resource groups, so that all SQL statements executed by a user use resources allocated to the corresponding group.

• SQL-level resource isolation

  SQL-level resource isolation provides a finer-grained isolation level than user-level isolation. It is implemented by binding SQL statements that meet certain conditions to specified resource groups for execution. This approach is typically suitable in scenarios where there are multiple accounts in the business. When processing an order for one account, a transaction is started and a batch of SQL statements related to that account is executed (usually by specifying the account value in the WHERE clause). Accounts may include large accounts (with larger data volumes) and small accounts (with smaller data volumes). To prevent large accounts from consuming all CPU resources and preventing small accounts' orders from being processed, SQL statements for handling different orders can be bound to different resource groups. After binding, the SQL statements for different orders will use the resources of their respective resource groups.

• Function-level resource isolation

  Function-level resource isolation isolates the resources used by each task by specifying the mapping between background tasks and resource groups. It is used to control the CPU and IOPS usage of background tasks.

  Currently, you can control the resource usage of the following background tasks corresponding to DAG threads:

  • COMPACTION_HIGH: Mini merge and DDL KV merge tasks
  • HA_HIGH: High-priority, high-reliability tasks such as replication, rebuild, and recovery
  • COMPACTION_MID: Minor merge tasks
  • HA_MID: Medium-priority, high-reliability tasks, such as migration tasks
  • COMPACTION_LOW: Major merge tasks
  • HA_LOW: Low-priority, high-reliability tasks such as backup and backup cleanup
  • DDL: Tasks for scenarios such as unique index verification and data replenishment after column deletion
  • DDL_HIGH: Minor compaction tasks for DDL MemTables
  • CLOG_LOW: Physical standby database and CDC read tasks
  • CLOG_MID: Tasks such as local disk reading for log archiving
  • CLOG_HIGH: Tasks such as writing clogs to the local disk and reading from the local disk for follower replicas
  • OPT_STATS: Statistical information collection tasks
  • GC_MACRO_BLOCK: Macroblock recycling and reuse tasks
  • SQL_AUDIT: SQL audit log persistence to disk
  • IMPORT: Import tasks
  • MVIEW: Materialized view background tasks (for V4.3.5, supported starting from V4.3.5 BP2)
  • REPLAY_HIGH: Log replay (for V4.3.5, supported starting from V4.3.5 BP2)