不看死不瞑目的文档 :Solaris container - Dynamic Resource Pools
来源:互联网 发布:miracast软件下载 编辑:程序博客网 时间:2024/05/16 07:41
Some situations may be best served by partitioning available system resources, such as processors, into a number of discrete resource partitions. There are several reasons why this may be useful:
_ Enforcing hard limits on the use of a resource. For instance, by creating a processor set and binding a process, project or zone to it, the CPU usage of the bound processes is effectively limited to the CPUs in the processor set. These processes cannot use processors outside of their set.
_ Providing a guaranteed quantity of a resource. If an application requires a certain amount of CPU resources at all times, a processor set can be created for use by the application, thereby reserving the CPUs for application processes. Processes not bound to the set are unable to run on the processors in that set.
_ Setting expectations. When deploying applications on a large server in phases, users may become accustomed to having fast response times as all resources are available to the application. As more applications are deployed, users may perceive a performance degradation. By partitioning the system so that the application received only the resources it needs, expectations can be set correctly from the start
_ Partitioning by function, such as creating a partition for interactive users and a partition for batch jobs.
Processor Sets
The ability to partition a server using processor sets has been available since version 2.6 of the Solaris Operating System. Every system has at least one processor set, the system or default processor set that contains all of the processors in the system. Additional processor sets can be dynamically created and removed on a running system using the psrset(1M) command, provided that at least one CPU remains for the system processor set. Processes are bound to the default processor set by default, and can be bound to other processor sets on-the-fly. It is important to note that partitioning a system using processor sets may lead to under utilization of the server since only processes bound to the processor set may use the processors in the set. If these processes do not use all of available CPU resources, the remaining CPU capacity in the set remains unused.
While processor sets are very useful, managing them can be a little umbersome. System administrators must specify the physical CPU ID of the processor to add to a processor set. Since the physical ID of a CPU is hardware dependent, it varies between different hardware platforms, creating a close coupling between the processor set definition and the underlying hardware. Also, on systems that support Dynamic Reconfiguration, processors can be added and removed while the system is on-line. If a processor to be removed is used in a processor set, the system administrator must manually remove that processor from the set before the processor can be removed from the system. This requires the system administrator to have intimate knowledge of the configured processor sets and the hardware. Processor sets are referenced by a system generated ID, making it hard to remember what a specific set is used for, especially when multiple processor sets are present.
Resource Pools
The introduction of Resource Pools in the Solaris 9 OS significantly enhanced the ability to partition the system. Resource Pools provide a mechanism to create a persistent configuration of resource sets such as processor sets. The Resource Pools framework removes the link between the intention of the system administrator and the underlying hardware. Instead of creating a processor set by specifying physical CPU IDs, system administrators can now
create a processor set with a chosen name by specifying the number of processors required, rather than their physical IDs. As a result, the definition of the processor set is no longer tied to a particular type of hardware.
System administrators can also specify a minimum and maximum number of processors for a set. The system assigns a number of processors between these values when creating the processor set on a specific system. This allows for more generic definitions that can be shared between systems. A configuration defining a set with at least one CPU and a maximum of three CPUs could be instantiated on a two-way system as well as on a larger server with more processors. Moving the definition to the larger server does not require any adjustment by the system administrator. The number of processors in the set on the larger server could be higher, depending on other processor sets defined in the system. The Resource Pools framework balances the number of processors in the set within the constraints set by the administrator.
On systems that support Dynamic Reconfiguration, the framework ensures that constraints are still met when removing processors from the system. If the total number of processors drops below the minimum number required for the active configuration, the Dynamic Reconfiguration operation is denied. If one of the processors being removed is part of a processor set, the system reconfigures all processor sets in the system so that the processor is no longer in a set. Adding CPUs to a running system also causes a reconfiguration of processor sets, depending on the constraints set by the administrator.
Multiple configurations can be defined to adapt to changing resource requirements such as seasonal workloads or different daily and nightly workloads. The appropriate configuration can be instantiated by invoking the pooladm(1M) command manually or from a cron(1M) job.
Binding Processes To Pools
Instead of binding a process to a processor set directly, a process is bound to a Resource Pool using the poolbind(1M) command. A Resource Pool (or pool) is a logical collection of resource sets such as processor sets. While the processor set is the only type of resource set available in the Solaris OS, the resource pool abstraction allows other types of resource sets, such as memory sets, to be added in later Solaris OS versions.
A pool can optionally be associated with a scheduling class such as the Fair Share Scheduler (FSS) or the Real Time (RT) scheduling class. Processes bound to the pool are subject to that pool’s scheduler, allowing the system to use different schedulers for different types of workloads. A server can be partitioned into two pools, one pool using the Fair Share Scheduler for applications, and a second pool using the Time Share scheduler (TS) for interactive users.
Multiple pools can be linked to the same resource set. As a result, it is possible to have a system with one processor set and several pools associated with the same processor set. This may not seem useful in a world with only processor sets. However, when other types of resource sets become available, it will be possible to let pools share a common processor set while giving each pool its own memory set, for instance.
The poolbind(1M) command allows administrators to bind processes, tasks, projects and zones to pools. A default pool binding for projects can be established by adding the project.pool attribute to the project entry in the project database. All processes started in the project are bound to the pool automatically. While the project.pool attribute designates only the default pool to bind to, specific processes in a project can still be bound to other pools if desired.
Fair Share Scheduler and Processor Sets
The previous discussion of the Fair Share Scheduler assumed all processors reside in the same processor set. When processor sets are present, the Fair Share Scheduler treats every processor set as a separate partition. CPU entitlement for a project is based on CPU usage in that processor set only. The CPU usage of a project in a processor set does not influence its entitlement in a different processor set. The Fair Share Scheduler calculates the proportion of CPU resources allocated to a project in a processor set by dividing the shares of the project by the number of shares of active projects in the processor set.
For example, consider a system with two processor sets, each containing one processor. Project A has two shares, and project B has one share. Both projects have enough processes to use all available CPU resources. Project B is the only one running in the first processor set. Since it is the only project in this set, project B is entitled to all CPU resources in the set. Both projects run in the second processor set. The number of active shares in this processor set is three (two from project A and one from project B). As a result, project A is entitled to of the processor set and project B is entitled to . Project B’s CPU use in the first processor set does not influence its entitlement in the second processor set.
Dynamic Resource Pools
In the Solaris 10 OS the Resource Pools facility has been further extended to provide automated resource allocation based on resource demands in the system and usage objectives set by the system administrator. This relieves system administrators from deciding how to optimally partition available resources for the current workload. Previously system administrators had to manually reassign resources to adapt to changing workloads. While fairly easy for relatively static workloads, this task may be challenging in an environment with highly variable resource demands.
Automated Resource Allocation
The Dynamic Resource Pools resource controller daemon poold(1M) is responsible for maintaining the resource allocation objectives set by system administrators. Toward this end, it creates an inventory of all available resources in the system. It continually monitors the active workloads in the system to determine if usage objectives can be met. If the resource controller detects that an objective is no longer being met, it evaluates possible alternative resource configurations to see if they can meet the objectives. If a viable alternative configuration exists, the resource controller reconfigures the resources accordingly. For processor sets, this is accomplished by moving processors between processor sets. If no alternative configuration exists that can meet objectives, no reconfiguration occurs. An appropriate message is logged, and the resource controller resumes workload monitoring.
Adding or removing resources using Dynamic Reconfiguration can also trigger a reconfiguration by the resource controller as the amount of available resource changes. Adding CPU capacity to a constrained system may create the opportunity for the resource controller to create a configuration that can meet objectives. Likewise, removing CPU capacity from the system may lead to the objectives no longer being met by the configuration.
Changes made to the objectives themselves by system administrators can also cause the resource controller to re-evaluate the configuration. The resource controller keeps a history of decisions made in the past, enabling it to rule out configuration changes that did not lead to improvement.
Even if the process of reconfiguration is automatic, system administrators can still directly manipulate the active configuration by transferring processors from one set to another. Note that doing so may or may not trigger actions by the resource controller.
Configuration Objectives
The resource controller offers several configuration objectives to influence decisions regarding possible resource configurations. These objectives can be combined and objectives can be assigned a precedence over each other. System administrators can choose from a number of different configuration objectives:
_ wt-load
This objective favors configurations that match resource allocations to resource demands. When this objective is in effect, a resource set that uses more resources is given more resources (within the minimum and maximum properties for the set).
_ locality
This objective is used to instruct the resource controller to take resource locality into consideration when allocating resources. On large servers such as the Sun Fire™ 15K server, the latency between resources on the same board and on a different board can vary. Depending on the application, latency may or may not be important. The locality objective allows the administrator to express the need for resource locality.
_ utilization
This objective favors configurations that allocate resources to partitions that are not meeting their utilization objective. System administrators can set target utilizations on the set using “less than”, “greater than” and “about” operators. The “less than” and “greater than” objectives can be combined to specify a target utilization range, such as between 50% and 80% utilization.
The configuration objectives are detailed in the libpool(3LIB) manual page.
Monitoring Resource Pools
System resource utilization can be monitored using the poolstat(1M) utility. This utility shows statistical data for every pool in the system. Data displayed includes the minimum, maximum and current size of the resource set, a measure of how much of the resource set is currently in use, as well as the load on the resource set. The decisions made by the resource controller can be observed by consulting the /var/log/pool/poold log file.
Commands
The following commands are available to administer resource pools:
Command
Description
pooladm(1M)
Activate and deactivate the pools facility
poolcfg(1M)
Create and modify resource pool configuration files
poold(1M)
Monitors resource usage and adjusts resource allocation
poolbind(1M)
Bind processes, tasks, projects and zones to a pool
poolstat(1M)
Report active pool statistics
- 不看死不瞑目的文档 :Solaris container - Dynamic Resource Pools
- 不看死不瞑目的文档 :Solaris container - Resource Pools Example
- 不看死不瞑目的文档 :Solaris container - Introduction
- 不看死不瞑目的文档 :Solaris container - Container Example
- 不看死不瞑目的文档 :Solaris container - Solaris Zone
- 不看死不瞑目的文档 :Solaris container - Solaris Zone Example
- 不看死不瞑目的文档 :Solaris container - workload Management
- 不看死不瞑目的文档 :Solaris container - workload Management Sample
- Solaris container – Resource Management
- Builder 在池中回收损坏的对象——Recycle broken objects in resource pools
- Solaris Container 演示
- TYPE POOLS 的用法...
- DMA pools的使用
- Solaris10的革命性功能之一 Solaris 10 N1 Grid Container
- Solaris10的革命性功能之一 Solaris 10 N1 Grid Container
- 《三国演义》中死不瞑目的十大风流人物
- 苹果官方文档:使用Autorelease Pools
- weblogic JDBC Connection Pools--转官方文档
- 防止页面刷新问题
- 一个简单css效果
- Javascript截取字符串的两个方法
- 这几天打工挣钱来着
- 学习.Net的经典网站
- 不看死不瞑目的文档 :Solaris container - Dynamic Resource Pools
- 存储过程__时间段内查询 以字符串形式输入SQL语句
- 解决document.body.scrollTop总是零的问题
- [转载]盛大技术经理金万钠谈:技术高手的十三个原则
- 阿翔编程学-计算机软件开发文档编写指南
- MYSEE正式宣布启动OpenMysee
- Div+CSS+JS树型菜单,可刷新 (Good)
- php5安装详解
- 基于角色的权限设计