8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
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.
- Introduction to Dynamic CPU Scaling
- CPU_COUNT in a PDB (12.2)
- The Issue With CPU_COUNT
- CPU_MIN_COUNT in a PDB (19.4 and 21c)
- Dynamic CPU Scaling Considerations
Related articles.
- Multitenant : Dynamic CPU Scaling
- Multitenant : Resource Manager with Container Databases (CDB) and Pluggable Databases (PDB) in Oracle Database 12c Release 1 (12.1)
- Multitenant : Resource Manager PDB Performance Profiles in Oracle Database 12c Release 2 (12.2)
- Multitenant : All Articles
- Resource Manager Quick Links : 8i, 9i, 10g, 11gR1, 11gR2, 12cR1, 12cR2, All 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.
- Multitenant : Resource Manager with Container Databases (CDB) and Pluggable Databases (PDB) in Oracle Database 12c Release 1 (12.1)
- Multitenant : Resource Manager PDB Performance Profiles in Oracle Database 12c Release 2 (12.2)
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.
The CPU_COUNT
can vary for each PDB, to indicate their relative performance requirements.
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.
- Resource Manager is an Enterprise Edition feature, so I assume this functionality is only available on Enterprise Edition.
- If you combine a CDB resource plan with
CPU_MIN_COUNT
andCPU_COUNT
settings in a PDB, the most restrictive limit will apply. - If unset, the
CPU_COUNT
of the PDB matches that of the instance, which would allow all idle threads to be used by any PDB. On the surface that sounds good, but we must consider the impact on the user's perception of performance on a day-to-day basis. Sometimes they might be using all the threads on the instance. Other times they may be using a small fraction of a thread. The inconsistency of the performance can raise concerns. Christian Craft wrote a blog post about dynamic cpu scaling, where he suggested defining a ratio between the upper and lower boundary, for example 3:1, so performance doesn't vary too wildly. This sounds very sensible. - In Oracle 19c we are allowed to use 3 user-defined pluggable databases without needing the Multitenant Option license. So even without the full option, this may still be useful.
- If you are selling PDBs to customers, you will need to plan your PDB Lockdown Profiles carefully, or the customer could manually change their
CPU_MIN_COUNT
andCPU_COUNT
settings.
For more information see:
- CPU_COUNT
- CPU_MIN_COUNT
- Multitenant : Dynamic CPU Scaling
- Multitenant : Resource Manager with Container Databases (CDB) and Pluggable Databases (PDB) in Oracle Database 12c Release 1 (12.1)
- Multitenant : Resource Manager PDB Performance Profiles in Oracle Database 12c Release 2 (12.2)
- Instance Caging to Manage CPU Usage in Oracle Database 11g Release 2
- Multitenant : All Articles
- Resource Manager Quick Links : 8i, 9i, 10g, 11gR1, 11gR2, 12cR1, 12cR2, All Articles
Hope this helps. Regards Tim...