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

An alternative approach would be to add the PID of your current shell to the tasks pseudo-file in the control
group directory. This way all the shell's child processes automatically belong to the control group:

[oracle@server1 ~]# echo $$ > /cgroups/oracle_cpuset/db1/tasks

Now start the Oracle database as normal. Since the oracle account has been specified as an administrator of the
cgroup during its creation, this operation is valid.
In addition to the manual way of adding processes to cgroups, you can make use of the new initialization
parameter processor_group available on Linux and Solaris. So instead of using cgexec , you simply set the
initialization parameter to point to the existing cgroup:

SQL> show parameter processor_group_name

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
processor_group_name string db1

There are a few ways to validate the cgroup mapping. The most common are probably these:

taskset command • The

/proc/pid/cgroup pseudo file • Checking the

ps command
Using the taskset approach, you need the process ID of your database first:

• Using custom options to the

[oracle@server1 ~]# ps -ef | grep CDB1
oracle 2149 1 0 14:24 ? 00:00:00 ora_pmon_CDB1
oracle 2151 1 0 14:24 ? 00:00:00 ora_psp0_CDB1
oracle 2153 1 1 14:24 ? 00:00:06 ora_vktm_CDB1

[root@server1 ~]# taskset -cp 2149
pid 2149's current affinity list: 0-5

This confirms that the cgroup settings are indeed in place. If you want to know the name associated with the
control group as well, check the /proc entry for the process:

[oracle@server1 ~]# cat /proc/2149/cgroup | grep cpuset
1:cpuset:/db1

And finally, you can view the same information with the ps command as well. Feel free to remove fields
you do not need:

[oracle@server1 ~]# ps -ax --format uname,pid,cmd,cls,pri,rtprio,cgroup
...
oracle 2149 ora_pmon_CDB1 TS 19 - ... cpuset:/db1
oracle 2151 ora_psp0_CDB1 TS 19 - ... cpuset:/db1
oracle 2153 ora_vktm_CDB1 RR 41 1 ... cpuset:/db1
...

With that knowledge it should be relatively simple to track down shared pool and other memory related
problems with the database.