Supporting Hardware - Expert Consolidation in Oracle Database 12c - page 85

[--shmid id] --shm shmkeyfile | --file tmpfsfile
[--huge] [--touch]
memory policy | --dump | --dump-nodes

memory policy is --interleave, --preferred, --membind, --localalloc
nodes is a comma delimited list of node numbers or A-B ranges or all.
cpus is a comma delimited list of cpu numbers or A-B ranges or all
all ranges can be inverted with !
all numbers and ranges can be made cpuset-relative with +
the old --cpubind argument is deprecated.
use --cpunodebind or --physcpubind instead
length can have g (GB), m (MB) or k (KB) suffixes

The meaning of all these are well described in the manual page for numactl . However, there is a better way to
control memory and process allocation described in the next section. Although the Oracle database has supported NUMA
for quite a while, you should be very careful to set the necessary NUMA initialization parameters in an instance. I would
like to encourage you to resort to Control Groups instead, unless you are on Oracle Linux 5 without the Unbreakable
Enterprise Kernel. But even then it is important, just as the My Oracle Support notes say, to thoroughly test the implication
of enabling NUMA support.

Control Groups
Control Groups, or cgroups for short, are an interesting new feature that made it into the latest enterprise Linux
kernels. Control groups are available with Oracle's Kernel UEK in Oracle Linux 5 or with Oracle Linux 6, where it does
not matter which kernel you use. Control Groups are a great way to divide a powerful multi-core, NUMA-enabled
server into smaller, more manageable logical entities. Some of the concepts you will read about in this section sound
similar to Solaris projects, which is part of the Solaris resource management framework.

Not ■ You can read more about Solaris Zones in Chapter 4.

The current Linux implementation is not quite as advanced as its Solaris counterpart yet. But who knows, maybe
the Linux community will get a very similar feature: development on LXC or Linux Containers has already started to
be more serious.
You read in the previous section that modern computer systems have local and remote memory in a non-uniform
memory architecture. Depending on your system's micro architecture, accessing remote memory can be more costly,
or a lot more costly than accessing local memory. It is a good idea to access local memory if possible, as you have
seen in the previous section. Very large multi-processor systems with more than four sockets can easily be divided
vertically into logical units matching a socket. In such a situation it is crucial to have enough local memory available!
Assuming that your system has four NUMA nodes and 64 GB of memory, you would expect to see each NUMA node to
have approximately 16 GB RAM.
Control Groups are based on grouping processes into subsystems, such as memory and CPU. All children of
processes belonging to a control group will also automatically be associated with that cgroup. Cgroups are not limited
to managing CPU and memory: further subsystems have been added to the framework. You can query your system to
learn more about which subsystem is available and in use:

[root@server1 cgroup]# lssubsys -am
cpuset /cgroup/cpuset
cpu /cgroup/cpu
cpuacct /cgroup/cpuacct