How GaussDB’s Fine‑Grained Resource Control Optimizes Multi‑Tenant Performance

Background

Enterprises have long required resource governance and isolation within database clusters. Huawei Cloud GaussDB, an enterprise‑grade distributed database, addresses these needs by offering fine‑grained resource control.

Technical Architecture

GaussDB introduces a resource‑pool module that manages CPU, memory, and I/O. Users create a resource pool, assign a share of CPU/memory/I/O, and bind the pool to a user. Jobs executed by that user are subject to real‑time control in the kernel optimizer, execution engine, and storage engine.

Example: a company with three workloads (OLTP, reporting, low‑priority) can allocate CPU shares of 50 %, 30 %, and 10 % via resource‑pool configuration.

create resource pool respool_tp with(control_group="cgroup_tp", max_dynamic_memory="5GB", max_shared_memory="5GB", io_limits=50, io_priority="High");
alter role tp_user RESOURCE POOL 'respool_tp';

create resource pool respool_report with(control_group="cgroup_report", max_dynamic_memory="3GB", max_shared_memory="3GB", io_limits=30, io_priority="Medium");
alter role report_user RESOURCE POOL 'respool_report';

create resource pool respool_other with(control_group="cgroup_other", max_dynamic_memory="1GB", max_shared_memory="1GB", io_limits=10, io_priority="Low");
alter role other_user RESOURCE POOL 'respool_other';

Key Capabilities

CPU Control

CPU is governed at the resource‑pool level via Linux control groups (cgroups). GaussDB builds a hierarchical cgroup model to isolate database processes, background threads, and user jobs. Users can set CPU percentages and core limits for root, backend, and class groups, and further create workload groups for finer control.

gs_cgroup -c -S cgroup_tp -s 50;
gs_cgroup -c -S cgroup_report -s 30;
gs_cgroup -c -S cgroup_other -s 10;

Two issues: binding threads to cgroups incurs overhead, and cgroup effectiveness peaks when thread count scales with CPU.

GaussDB mitigates this by introducing thread groups that match the CPU share of their associated cgroup.

Memory Control

GaussDB allows dynamic memory and shared cache limits via max_dynamic_memory and max_shared_memory in a resource pool. When the dynamic memory limit is reached, further memory allocation fails; shared cache limits trigger eviction before new allocation.

Session‑level and statement‑level memory can be limited with GUC parameters session_max_dynamic_memory and query_max_mem.

I/O Control

I/O is managed logically: each 6000 rows (configurable) count as one I/O operation. When a pool’s I/O threshold is exceeded, requests are queued and later serviced based on wait‑time criteria. Two modes exist: a fixed‑value mode and a priority mode (High, Medium, Low) that adjusts I/O priority when disk utilization is high.

Connection and Concurrency Control

Resource pools can define max_connections and max_concurrency to limit the number of simultaneous connections and concurrent jobs.

alter resource pool respool_tp with(max_connections=-1, max_concurrency=-1);
alter resource pool respool_report with(max_connections=200, max_concurrency=100);
alter resource pool respool_other with(max_connections=100, max_concurrency=50);

Storage Space Control

GaussDB enforces storage quotas (perm, temp, spill) per user to prevent a single tenant from exhausting cluster storage.

alter user tp_user PERM SPACE '200G' TEMP SPACE '20G' SPILL SPACE '20G';
alter user report_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G';
alter user other_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G';

Feature Demonstration

A simple CPU‑control demo creates two resource pools with 20 % and 60 % CPU shares, binds users, and runs workloads while observing CPU usage via system tools and the GaussDB function gs_wlm_respool_cpu_info. The observed CPU usage converges to the configured 1:3 ratio, confirming effective control.

gs_cgroup -c -S class1 -s 20;
gs_cgroup -c -S class2 -s 60;

CREATE RESOURCE POOL xuuer_pool with(control_group = "class1");
CREATE RESOURCE POOL xyuser1_pool with(control_group = "class2");

create role user1 RESOURCE POOL 'xuuer_pool';
create role user2 RESOURCE POOL 'xyuser1_pool';

Conclusion

Fine‑grained resource control provides per‑tenant isolation for compute resources on each node and cluster‑wide storage control. It serves scenarios where data isolation is not critical but resource segregation among workloads is required. For environments needing both resource and data isolation, upcoming multi‑tenant database features should be considered.