Oracle NUMA绑定

Using PROCESSOR_GROUP_NAME to bind a database instance to CPUs or NUMA nodes on Linux (文档 ID 1585184.1)

转到底部


In this Document

 

Purpose

 

 

Details

 

 

Step 1 - Configuring the Linux cgroup

 

 

Step 2 - Configuring the Database

 

 

Best Practices

 

 

Linux Cgroups vs Virtualization

 

 

Support and Recommended Bug Fixes

 

 

Bug Number

 

 

Description

 

 

Recommended Releases

 

 

Bug 17013349

 

 

MISC DEFECTS IN CGROUP CODE

 

 

12.1.0.1 (fixed in 12.1.0.2)

 

 

Additional Information

 

 

References


  1. Applies to:

Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Linux x86-64

  1. Purpose

This document provides a step-by-step guide for binding a database instance to a subset of a server's CPUs and memory, using Linux cgroups.  Cgroups provide a way to create a named set of CPUs and memory.  A database instance that is associated with this cgroup can only use its CPUs and memory.  

Using Linux cgroups, a DBA that is consolidating multiple database instances on a single server can

  1. Physically isolate database instances onto different CPUs
  2. Bind instances to specific NUMA nodes to improve performance on NUMA-based systems.
  1. Details
  1. Step 1 - Configuring the Linux cgroup

Use the attached script, setup_processor_group.sh, to create and modify Linux cgroups.  You must run this script as root.

First, check the number of CPUs, the NUMA configuration, and the existing cgroups (if any) for your system:

setup_processor_group.sh –show

Next, prepare the system to use cgroups (this command can be repeated):

setup_processor_group.sh –prepare

To check if the system is indeed ready:

setup_processor_group.sh –check

To create a new cgroup "mycg" for user "oracle" in group "dba" with CPUs 0 and 1, use the "-create" option.  With the "-cpu" option, you can provide either a comma-separated list or a range, e.g. "–cpus 0-7,16-23".

setup_processor_group.sh –create –name mycg –cpus 0,1 -u:g oracle:dba

Or, create a new cgroup "mycg" for user "oracle" in group "dba" with NUMA nodes 1 and 2, using the "-numa_nodes" option.  You cannot use the "-create" option with both "–cpus" and "–numa_nodes".

setup_processor_group.sh –create –name mycg –numa_nodes 1,2 -u:g oracle:dba

To update an existing cgroup "mycg" with new values:

setup_processor_group.sh –update  -name mycg –cpus 2,3 -u:g oracle:dba

To delete the cgroup "mycg": 

setup_processor_group.sh –delete –name mycg

  1. Step 2 - Configuring the Database

To bind a database instance to a cgroup, set the Oracle initialization parameter, PROCESSOR_GROUP_NAME, to the name of the cgroup.  The cgroup was named through the "setup_processor_group.sh -name" option.  PROCESSOR_GROUP_NAME is a static parameter.  Therefore, the database instance must be restarted in order for the parameter to take effect.

To verify that the database instance has successfully bound itself to the cgroup, check for this message in the alert log:
"Instance started in processor group mycg"

When a database instance is successfully running in a cgroup, the default value of the Oracle initialization parameter, CPU_COUNT, is set to the number of CPUs in the cgroup. 

show parameter cpu_count

If you have explicitly set CPU_COUNT, you should consider clearing it so that CPU_COUNT is set to the cgroup's value:

alter system set cpu_count = 0;

Use this Linux command to verify that a particular database process is running in the cgroup (substitute <pid> with the process id).  In the output, you should see the cgroup name after the string "cpuset:/".

cat /proc/<pid>/cgroup

Use this Linux command to see all processes that are running in the cgroup (substitute <mycg> with your cgroup name).

cat /mnt/cgroup/<mycg>/tasks

  1. Best Practices

(1) Note that Linux cgroups allow databases and applications that are not associated with the cgroup to use its CPU and memory.

(2) For processors with hyper-threading (e.g. x-86), configure cgroups out of CPU threads, using the "-cpus" option, from the minimum number of CPU cores and sockets.  Do not assign the CPU threads on a core to more than one cgroup.  These best practices enable much better isolation and performance since CPUs on a core share many common resources, such as parts of the execution pipeline, caches, and TLBs.  For a list of the CPU threads, cores, and sockets, use the following commands:

cat /proc/cpuinfo  | grep processor  (lists CPU threads)

cat /proc/cpuinfo | grep "physical id" | sort | uniq  (lists the CPU sockets)

cat /proc/cpuinfo | egrep "core id|physical id"  (lists CPU cores and sockets)

(3) Create cgroups with at least 2 CPU cores.

(4) For NUMA systems (e.g. Exadata X4-8), configure the cgroup from NUMA nodes, using the "-numa_nodes" option.  The "-numa_nodes" option will ensure that the database instance allocates local memory for both SGA and PGA, resulting in improved database performance.

(5) When consolidating a large number of databases, consider creating a few cgroups and binding multiple database instances to each cgroup.  For example:

  • Create one cgroup per NUMA node.  Bind multiple database instances to each NUMA node's cgroup.
  • Create 2 cgroups, one for test databases and one for standby databases.
  1. Linux Cgroups vs Virtualization

Linux cgroups and virtual machines (VMs) are both effective tools for consolidating multiple databases on a server.  Both tools provide resource isolation by dedicating CPU and memory to a database instance.  Database instances on VMs are isolated in a similar way as database instances on separate physical servers.  While this isolation offers many obvious advantages, it also has the following disadvantages:

  • Oracle Clusterware must be installed for each virtual machine.  Databases in cgroups can share one instance of the Oracle Clusterware.
  • Exadata does not currently support virtualization. 

Using Linux cgroups does not reduce Oracle database licensing costs.  The license is based on the number of CPUs on the server, not the database's cgroup size.

  1. Support and Recommended Bug Fixes

Linux cgroups are available in Oracle Linux 5 with UEK2, Oracle Linux 6, and RHEL 6+.

The PROCESSOR_GROUP_NAME parameter is available from 12.1.0.1.  The recommended bug fixes are as follows:

  1. Bug Number
  1. Description
  1. Recommended Releases
  1. Bug 17013349
  1. MISC DEFECTS IN CGROUP CODE
  1. 12.1.0.1 (fixed in 12.1.0.2)
  1. Additional Information

For more information on Instance Caging, see MOS Document 1362445.1.

 

猜你喜欢

转载自blog.csdn.net/notbaron/article/details/81147814