Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: Oracle Solaris Zones, Oracle Solaris 10 Zones, and Resource Management Oracle Solaris 11.1 Information Library |
Part I Oracle Solaris Resource Management
1. Introduction to Resource Management
2. Projects and Tasks (Overview)
3. Administering Projects and Tasks
4. Extended Accounting (Overview)
5. Administering Extended Accounting (Tasks)
6. Resource Controls (Overview)
7. Administering Resource Controls (Tasks)
8. Fair Share Scheduler (Overview)
FSS and Processor Sets Examples
Combining FSS With Other Scheduling Classes
Setting the Scheduling Class for the System
Scheduling Class on a System with Zones Installed
9. Administering the Fair Share Scheduler (Tasks)
10. Physical Memory Control Using the Resource Capping Daemon (Overview)
11. Administering the Resource Capping Daemon (Tasks)
13. Creating and Administering Resource Pools (Tasks)
14. Resource Management Configuration Example
15. Introduction to Oracle Solaris Zones
16. Non-Global Zone Configuration (Overview)
17. Planning and Configuring Non-Global Zones (Tasks)
18. About Installing, Shutting Down, Halting, Uninstalling, and Cloning Non-Global Zones (Overview)
19. Installing, Booting, Shutting Down, Halting, Uninstalling, and Cloning Non-Global Zones (Tasks)
20. Non-Global Zone Login (Overview)
21. Logging In to Non-Global Zones (Tasks)
22. About Zone Migrations and the zonep2vchk Tool
23. Migrating Oracle Solaris Systems and Migrating Non-Global Zones (Tasks)
24. About Automatic Installation and Packages on an Oracle Solaris 11.1 System With Zones Installed
25. Oracle Solaris Zones Administration (Overview)
26. Administering Oracle Solaris Zones (Tasks)
27. Configuring and Administering Immutable Zones
28. Troubleshooting Miscellaneous Oracle Solaris Zones Problems
Part III Oracle Solaris 10 Zones
29. Introduction to Oracle Solaris 10 Zones
30. Assessing an Oracle Solaris 10 System and Creating an Archive
31. (Optional) Migrating an Oracle Solaris 10 native Non-Global Zone Into an Oracle Solaris 10 Zone
32. Configuring the solaris10 Branded Zone
33. Installing the solaris10 Branded Zone
Assume you have a system with two CPUs running two parallel CPU-bound workloads called A and B, respectively. Each workload is running as a separate project. The projects have been configured so that project A is assigned SA shares, and project B is assigned SB shares.
On average, under the traditional TS scheduler, each of the workloads that is running on the system would be given the same amount of CPU resources. Each workload would get 50 percent of the system's capacity.
When run under the control of the FSS scheduler with SA=SB, these projects are also given approximately the same amounts of CPU resources. However, if the projects are given different numbers of shares, their CPU resource allocations are different.
The next three examples illustrate how shares work in different configurations. These examples show that shares are only mathematically accurate for representing the usage if demand meets or exceeds available resources.
If A and B each have two CPU-bound processes, and SA = 1 and SB = 3, then the total number of shares is 1 + 3 = 4. In this configuration, given sufficient CPU demand, projects A and B are allocated 25 percent and 75 percent of CPU resources, respectively.
If A and B have only one CPU-bound process each, and SA = 1 and SB = 100, then the total number of shares is 101. Each project cannot use more than one CPU because each project has only one running process. Because no competition exists between projects for CPU resources in this configuration, projects A and B are each allocated 50 percent of all CPU resources. In this configuration, CPU share values are irrelevant. The projects' allocations would be the same (50/50), even if both projects were assigned zero shares.
If A and B have two CPU-bound processes each, and project A is given 1 share and project B is given 0 shares, then project B is not allocated any CPU resources and project A is allocated all CPU resources. Processes in B always run at system priority 0, so they will never be able to run because processes in project A always have higher priorities.