Overview

This topic provides an overview of resource isolation, including the concepts, resource isolation types, and application scenarios.

Control group (cgroup) is a mechanism provided by the Linux kernel to aggregate or divide, based on specialized behavior, a series of tasks and their subtasks into different groups that are graded based on resources, thereby providing a unified framework for system resource management.

In the current version of OceanBase Database, worker threads and most background threads are identified by tenant, and network threads are shared. If you are an administrator, you can configure the cgroup system directory and then use the DBMS_RESOURCE_MANAGER package to control the CPU and input/output operations per second (IOPS) resource usage of tenants.

DBMS_RESOURCE_MANAGER system package

In OceanBase Database, the procedural language (PL) package DBMS_RESOURCE_MANAGER is used to manage resource allocation in a database to implement resource isolation. This package is mainly used to maintain the following elements:

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

• Resource management plans: A resource management plan is a container of plan directives and specifies how resources are allocated to resource groups. You can activate a specific resource management plan to control the allocation of resources. A resource management plan can contain multiple plan directives. However, a resource management plan must not contain two identical plan directives.

• Plan directives: A plan directive associates a resource group with a resource management plan and specifies how resources are allocated to this resource group.

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

Resource isolation types

You can use the DBMS_RESOURCE_MANAGER package to configure the following types of resource isolation in a tenant based on the granularity of resource usage:

• User-level resource isolation

  User-level resource isolation specifies the mapping between a user and a resource group. All SQL statements initiated by the specified user can be executed by using only the resources in the resource group mapped to the user.

• SQL statement-level resource isolation

  SQL statement-level resource isolation is more fine-grained than user-level resource isolation. You can bind the SQL statements that meet a specified condition to a specified resource group to implement SQL statement-level resource isolation. If multiple accounts exist in the business system, when an order of an account is processed, a transaction is enabled to execute a batch of SQL statements related to this account. Generally, the account is specified in the WHERE clause. Different accounts may involve different amounts of data. If accounts involving a large amount of data use up the CPU resources, the orders of accounts involving a small amount of data cannot be processed. You can bind SQL statements for processing different orders with different resource groups. In this way, SQL statements for different orders can use resources in different resource groups.

• Function-level resource isolation

  Function-level resource isolation specifies the mapping between a backend task and a resource group. In this way, resources are isolated for different types of tasks. At present, you can control the CPU resources available for the backend tasks corresponding to the directed acyclic graph (DAG) thread.

  The DAG thread corresponds to the following eight types of backend tasks:

  • compaction_high: mini merge and DDL KV merge tasks
  • ha_high: tasks with high priorities and requiring high reliability, such as replication, rebuild, and restore tasks
  • compaction_mid: minor merge tasks
  • ha_mid: tasks with medium priorities and requiring high reliability, such as migration tasks
  • compaction_low: major merge tasks
  • ha_low: tasks with low priorities and requiring high reliability, such as backup and backup cleanup tasks
  • ddl: tasks that are performed in scenarios such as unique index verification and data completion upon column deletion
  • ddl_high: minor compactions for DDL MemTables