不看死不瞑目的文档 ：Solaris container - Resource Pools Example

This chapter presents an example of using Resource Pools to partition the available CPU resources on a system. Partitioning enables minimum and maximum amounts of CPU resources to be guaranteed to applications. Continuing with the sales and marketing database example presented earlier, assume the following policies. The sales database instance should always have at least 2 CPUs available to ensure a minimum level of service. Extra CPU capacity could increase service levels and the sales business unit is willing to pay extra for increased service levels. The marketing database requires at least one CPU, and a maximum of two CPUs, to achieve business objectives. The marketing business unit is not willing to be charged for more than two CPUs. These policies should require no manual intervention by the system administrator to adjust the number of CPUs in the processor sets.

Dynamic Resource Pools can be used to implement these requirements by creating a large processor set with at least two CPUs for the sales database, and a small processor set with at least one CPU and at most two CPUs for the marketing database. All remaining CPUs remain in the default processor set present on every system and which contains at least one CPU.

When implemented on a system with six CPUs, the following configurations are possible:

Default Processor Set

Small Processor Set

Large Processor Set

2

2

2

1

2

3

1

1

4

2

1

3

3

1

2

The number of CPUs in each processor set can be dynamically adjusted to current system load according to allocation objectives set by the system administrator. For example, if high demand is experienced for CPU resources in the large processor set, the system might move processors from the small or default processor sets to the large processor set. When demand in the large processor set decreases, the system may move processors to the small or default processor sets.

Because the pools facility is disabled by default, pools must first be enabled using the –e (enable) option of the pooladm(1M) command. This creates a configuration with a processor set with all processors in the system and a default pool. The following output illustrates the configuration of a system with 6 CPUs after the pooladm -e command is run, and shows the default pool named pool_default and the default processor set pset_default.

 

# pooladm -e

# pooladm

system blondie

string system.comment

int system.version 1

boolean system.bind-default true

int system.poold.pid 611

pool pool_default

int pool.sys_id 0

boolean pool.active true

boolean pool.default true

int pool.importance 1

string pool.comment

pset pset_default

pset pset_default

int pset.sys_id -1

boolean pset.default true

uint pset.min 1

uint pset.max 65536

string pset.units population

uint pset.load 447

uint pset.size 6

string pset.comment

cpu

int cpu.sys_id 1

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 0

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 3

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 2

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 11

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 10

string cpu.comment

string cpu.status on-line

 

While the set currently contains six CPUs, the minimum (one) and maximum (65,536) number of CPUs are also set. Note the system.bind-default, pool.default and pset.default properties. These properties ensure that processes that do not bind to a specific pool are bound to the pool.default pool.

Note – This example assumes the users and projects created in Workload Management example still exist.

Creating a Pool

For the sales database, a processor set named large with at least two CPUs, and no upper bound on the number of CPUs, is created. Next, a processor set named small with at least one CPU and a maximum of two CPUs is created. A pool named sales is created and associated with the large processor set. A second pool named marketing is created and associated with the small processor set. Changes to the pools configuration can be made in two ways: to the active in-kernel configuration or to the /etc/pooladm.conf configuration file. The configuration contained in the /etc/pooladm.conf file can be instantiated by running the pooladm -c command. If desired, an alternate filename can be specified using the -f option. To save the currently active in-kernel configuration to a file, the pooladm –s command can be used. In this example, changes are made to the /etc/pooladm.conf configuration file, ensuring the changes persist across system reboots.

The initial configuration file is created from the running configuration, after which the processor sets and pools are added.

# poolcfg -c ’create pset large (uint pset.min=2;uint pset.max=65536)’

# poolcfg -c ’create pset small (uint pset.min=1;uint pset.max=2)’

# poolcfg -c ’create pool sales’

# poolcfg -c ’create pool marketing’

# poolcfg -c ’associate pool sales (pset large)’

# poolcfg -c ’associate pool marketing (pset small)’

These commands update the configuration contained in the /etc/pooladm.conf file, and have no effect on the active in-kernel configuration. This can be verified by displaying the active in-kernel configuration using the poolcfg(1M) command with the -d option.

Next, the configuration file is instantiated on the system. The processor set and the pool are created, and the system moves processors into the created processor set according to the available processors on the system and the pset.min and pset.max attributes of the configured processor sets. The in-kernel configuration now contains the following:

# pooladm -c

# poolcfg -dc info

system blondie

string system.comment

int system.version 1

boolean system.bind-default true

int system.poold.pid 611

pool marketing

int pool.sys_id 1

boolean pool.active true

boolean pool.default false

int pool.importance 1

string pool.comment

pset small

pool pool_default

int pool.sys_id 0

boolean pool.active true

boolean pool.default true

int pool.importance 1

string pool.comment

pset pset_default

pool sales

int pool.sys_id 2

boolean pool.active true

boolean pool.default false

int pool.importance 1

string pool.comment

pset large

pset large

int pset.sys_id 1

boolean pset.default false

uint pset.min 2

uint pset.max 65536

string pset.units population

uint pset.load 0

uint pset.size 2

string pset.comment

cpu

int cpu.sys_id 3

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 2

string cpu.comment

string cpu.status on-line

pset small

int pset.sys_id 2

boolean pset.default false

uint pset.min 1

uint pset.max 2

string pset.units population

uint pset.load 0

uint pset.size 2

string pset.comment

cpu

int cpu.sys_id 1

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 0

string cpu.comment

string cpu.status on-line

pset pset_default

int pset.sys_id -1

boolean pset.default true

uint pset.min 1

uint pset.max 65536

string pset.units population

uint pset.load 4

uint pset.size 2

string pset.comment

cpu

int cpu.sys_id 11

string cpu.comment

string cpu.status on-line

cpu

int cpu.sys_id 10

string cpu.comment

string cpu.status on-line

 

Binding to a Pool

The sales database project is bound to the sales pool by adding the project.pool attribute to the project entry for the ora_sales project. Every new process started in this project is bound to the sales pool by default.

# projmod -sK “project.pool=sales” ora_sales

# projmod -sK “project.pool=marketing” ora_mkt

# cat /etc/project

system:0::::

user.root:1::::

noproject:2::::

default:3::::

group.staff:10::::

group.dba:100:Oracle DBA:::project.max-shm-memory=(privileged,2147483648,deny)

ora_mkt:101:Oracle Marketing:oracle::project.cpushares=(

privileged,10,none);project.max-shmmemory=(

privileged,2147483648,deny);project.pool=marketing

ora_sales:102:Oracle Sales:oracle::project.cpushares=(

privileged,20,none);project.max-shmmemory=(

privileged,2147483648,deny);project.pool=sales

Existing processes in the project are still bound to the default pool; they can be moved to the sales pool using the poolbind(1M) command. The following command binds all processes currently running in the project ora_sales to the sales pool. Start a new process in the ora_sales project to verify the pool binding.

# poolbind -p sales -i project ora_sales

# su - oracle

$ newtask -p ora_sales

$ id -p

uid=100(oracle) gid=100(dba) projid=100(ora_sales)

bash-2.05b

$ poolbind -q $$

1520 sales

Transferring CPUs

The system creates processor sets on a particular system based on the pool configuration and the number of CPUs in the system. In this example using a six CPU system, all three processor sets are created with two CPUs. The system administrator can manually move processors from one processor set to another to shrink or enlarge a processor set depending on the CPU requirements of applications. For example, end of month processing may require the large pool to contain four CPUs. The extra CPUs can be moved from the small and default processors sets using the poolcfg(1M) command:

# poolcfg -dc ‘transfer 1 from pset pset_default to large’

# poolcfg -dc ‘transfer 1 from pset small to large’

Adapting to Load

So far, the pool configuration is static. Changes in system load do not lead to configuration changes. The system administrator must manually move processors between sets to react to changes in utilization. By setting an objective, the system administrator tells the system to adapt the number of processors in a set to system demand. In this example, the utilization objective is used to ensure utilization of the large and small processor sets is kept below 75 percent to allow for spikes in the load.

# poolcfg -dc ’modify pset large (string pset.poold.objectives="utilization<75")’

# poolcfg -dc ’modify pset small (string pset.poold.objectives=”utilization<75”)’’

# poolcfg -dc info

[...]

pset large

int pset.sys_id 1

boolean pset.default false

uint pset.min 2

uint pset.max 65536

string pset.units population

uint pset.load 182

uint pset.size 2

string pset.comment

string pset.poold.objectives utilization<75

[...]

Note – Until a patch for bug 6232648 is available, a workaround is needed for utilization objectives. Each processor set should have at least one 'pinned' CPU to prevent the issue described in the bug from occuring. The following command can be used to pin a CPU in a processor set. (Replace ID with the appropriate CPU ID.)

# poolcfg -dc ‘modify cpu ID (boolean cpu.pinned=true)’

To see how the system adapts to varying demand for CPU resources, load is generated in the small processor set. It currently contains only one CPU since the second CPU was moved by the administrator in Transferring CPUs earlier. When the load exceeds the 75% utilization objective, the system attempts to move a processor from another processor set into the small processor set.

$ id -p

uid=100(oracle) gid=100(dba) projid=101(ora_mkt)

$ /usr/sbin/poolbind -q $$

666 marketing

$ nspin -n 4

The file /var/log/pool/poold can be observed to see the actions taken by the resource controller, such as moving a processor from one processor set to another:

Mar 22 15:28:33 Monitoring INFO: all evaluated objectives satisfied

Mar 22 15:28:48 Monitoring INFO: all evaluated objectives satisfied

Mar 22 15:29:03 Monitoring INFO: pset small utilization objective not satisfied (1,

utilization, '<', 75) with utilization 85.99 (control zone bounds exceeded)

Mar 22 15:29:03 Monitoring INFO: reconfiguration required

Mar 22 15:29:03 Optimization INFO: from pset large to pset small components [cpu 2]

not applied due to poor past results

Mar 22 15:29:03 Optimization INFO: applying move from pset large to pset small

components [cpu 1]

Mar 22 15:29:03 Configuration INFO: reconfiguring...

Mar 22 15:29:03 Configuration INFO: configuration complete

As shown the above output, the system decides to move processor 1 from the large processor set to the small processor set to satisfy utilization objectives. Stopping the load in the small processor set and adding load in the large processor set causes another reconfiguration after some time to satisfy the utilization objective on the large processor set.

This example only shows a tiny fraction of the possibilities enabled by Dynamic Resource Pools. More complex objectives can be created, such as combining different types of objectives and setting the importance of these objectives in relation to each other. See the man page for libpool(3LIB) for more information on setting objectives.

Saving the Dynamic Configuration

The last few changes have been made to the in-kernel configuration. To keep these changes across reboots, the in-kernel configuration must be saved to a file using the pooladm –s command. This command saves the configuration to the /etc/pooladm.conf file. The system automatically instantiates the configuration from this file at boot time.