8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » 19c » Here

Multitenant : Dynamic CPU Scaling - Resource Manager Control of CPU using CPU_COUNT and CPU_MIN_COUNT

Resource Manager can control CPU usage in PDBs using the CPU_COUNT and CPU_MIN_COUNT parameters. Oracle call this Dynamic CPU Scaling. The genesis of this functionality began in Oracle 12.2, but Oracle 19.4 saw the introduction of the CPU_MIN_COUNT parameters.

Depending on the underlying architecture, the CPU_COUNT refers to the number of cores or threads available to the instance or PDB. We'll use the term threads, but if your architecture doesn't support multiple threads per core, then threads are synonymous to cores.

Related articles.

Introduction to Dynamic CPU Scaling

It's always been possible to control CPU usage in a pluggable database using Resource Manager. Oracle 12.1 introduced CDB resource plans, and Oracle 12.2 simplified them by introducing PDB performance profiles. Using these, CPU control is based on shares and utilization percentages of the instance CPU. This is not the most intuitive of approaches.

Oracle 12.2 also introduced the ability to control the CPU usage of a pluggable database using the CPU_COUNT parameter. This feels a lot more straight forward. Oracle 19.4 introduced the CPU_MIN_COUNT parameter to make safe over-privsioning possible.

CPU_COUNT in a PDB (12.2)

From Oracle 12.2 onward the CPU_COUNT parameter can be set in a PDB, effectively allowing the PDB to be caged to a specific number of cores/threads. Resource manager must be enabled, so we need a CDB resource plan, or we can use the DEFAULT_PLAN in one or more of the open PDBs. In the following example we use the DEFAULT_PLAN in all the PDBs, and set the CPU_COUNT in each pluggable database.

conn / as sysdba

-- Switch to PDB1.
alter session set container = pdb1;

-- Set the DEFAULT_PLAN and the CPU_COUNT for the PDB.
alter system set resource_manager_plan = default_plan;
alter system set cpu_count=1;


-- Switch to PDB2.
alter session set container = pdb2;

-- Set the DEFAULT_PLAN and the CPU_COUNT for the PDB.
alter system set resource_manager_plan = default_plan;
alter system set cpu_count=2;

From this point onward, the PDBs will be constrained to using the number of threads specified by their CPU_COUNT parameter value.

The Issue With CPU_COUNT

When dealing with just the CPU_COUNT parameter, this feels similar to instance caging. We still have to make a hard decision. Do we partition the CPUs to guarantee each PDB will get it's share of CPU, but risk having idle threads. Or over-provision to reduce the chances of idle threads, but risk noisy neighbours affecting the performance of other PDBs.

The diagram below gives an example of the two provisioning methods in a container database with 8 threads available for database processing.

PDB CPU Count : Equal

The CPU_COUNT can vary for each PDB, to indicate their relative performance requirements.

PDB CPU Count : Differing

Oracle 19.4 allows us to do a hybrid of the two, allowing us to safely over-provision.

CPU_MIN_COUNT in a PDB (19.4 and 21c)

From Oracle 19.4 onward the CPU_MIN_COUNT and CPU_COUNT parameters can be set to provide a lower and upper boundary for CPU usage. Resource Manager will guarantee the CPU_MIN_COUNT lower limit is available when the system is under load, but when there is less load the PDB will be allowed to dynamically scale up to the CPU_COUNT upper limit. This way you are protecting the PDBs from noisy neighbours by reserving the CPU, but if the system is quiet the PDB is not so restricted, so idle cores/threads don't go to waste. If you are using Oracle 19.4 or above, you should probably use MIN_CPU_COUNT and CPU_COUNT in preference to just CPU_COUNT in the PDB.

In the following example we set a default value of CPU_MIN_COUNT in the root container. This will apply to all pluggable databases unless a PDB-specific value is set. In the pluggable databases we set PDB-specific CPU_MIN_COUNT and CPU_COUNT parameter values, remembering to set the DEFAULT_PLAN in at least one of the open PDBs to enable resource manager. In this case we set it in all PDBs.

conn / as sysdba

alter system set cpu_min_count="0.5";


-- Switch to PDB1.
alter session set container = pdb1;

-- Set the PDB-specific values.
alter system set resource_manager_plan = default_plan;
alter system set cpu_min_count=1;
alter system set cpu_count=2;


-- Switch to PDB2.
alter session set container = pdb2;

-- Set the PDB-specific values.
alter system set resource_manager_plan = default_plan;
alter system set cpu_min_count=2;
alter system set cpu_count=4;

If you are running in a RAC environment, the documentation suggests the same instance-level CPU_COUNT value should be set on all instances. Remember, the CPU_MIN_COUNT and CPU_COUNT parameters are set in the PDB, so each RAC node will attempt to use the same limits. That might be impossible if some nodes have lower CPU_COUNT values.

The CPU_MIN_COUNT parameter can be set to decimal values between 0.1 and 0.95 in multiples of 0.05, or to integer values. The value can't exceed that of the CPU_COUNT parameter value. The CPU_COUNT parameter value in the pluggable database can't exceed that of the CPU_COUNT parameter value for the instance.

So we can think of the CPU_MIN_COUNT as our safe partitioned setting, and the CPU_COUNT as our risky over-provisioned setting. We guarantee protection from noisy neighbours when the system is under load, but we allow idle threads to be used by other PDBs when the system is under less load. Oracle call this Dynamic CPU Scaling.

Dynamic CPU Scaling Considerations

There are some things to consider when using dynamic CPU scaling.

For more information see:

Hope this helps. Regards Tim...

Back to the Top.