This chapter describes containers and projects and how to start the product.
The following topics are discussed:
A project is a container that has been associated with a host. A project helps organize and manage the collection of physical system resources. A project is useful when you implement an overall server consolidation plan. Projects offer the following features:
Setting minimum CPU reservations and memory caps for applications to help balance system resources
Each application is guaranteed the minimum CPU reservation and the optional memory cap set for its project. For example, an application-based project enables you to establish both a minimum CPU reservation and a memory cap for any application that runs on your network. When several projects are active on the same host, with each application in its own project, contention for system resources is reduced. In this situation, the resource boundaries set for each project are enforced by the Solaris kernel that operates on that host.
Tracking of resource utilization across a data center
The total amount of resources that are being used by the project is tracked, in part, with project membership. Each UNIX user must be assigned to a default project, although users and groups can belong to one or more projects. The processes that a UNIX user starts can be bound to any of the projects of which the user is a member. Projects use both project membership and resource pools to help track and control application resource consumption.
For more information about how projects work and the resource management tools they use, see Chapter 1, Introduction to Solaris Container Manager 3.6.1.
After the software is installed and set up, several default projects are available for your immediate use. You also create your own projects by using a wizard that guides you through the process. Every project is associated with a container. This container can be used over again for creating new projects. Projects provide the following advantages:
Ability to create multiple project instances with the identical set of CPU and memory resource boundaries.
Spreading multiple project instances across several hosts. Whereas a single active project cannot span multiple hosts, additional project instances with the same container can be spread across multiple hosts.
Shortens the time necessary to create a new project instance, enabling you to quickly apportion resources as needs fluctuate.
The GUI is browser based and provides three management views (tabs): one from the host perspective, one from the container perspective, and one for open alarms. You can further organize the host view and the container view by creating groups and selecting which elements the groups should contain.
Additionally, the processes running inside the container and the resources being used can be readily checked with the software. Several graphing options are also available to help assess the level of resource utilization per container or host, including the ability to export the data to a file. These features enable you to monitor and reassess resource consumption for the appropriate adjustments.
With the software's alarm feature you can be notified by email when a container's resource utilization reaches a threshold of your setting. Alarm icons are also visible in the GUI for both hosts and containers.
The resource change job feature enables you to schedule changes to current resource boundaries on one or more containers with one request. A wizard guides you through the steps required for creating or modifying a resource change job.
The container has the following properties:
Name
Description (optional)
Project type
Project name that is associated with the container
The UNIX users and groups that are associated with the container application
The match expression, if one exists
The name you assign to a container is permanent and cannot be changed. The project name is likewise permanent. The other identifying information for the container can be changed.
The container is saved by the software and is available for repeated use until the container is deleted. The project is a container that has been associated with a host. A project is active when it has been associated with a host, and its resource reservations have been set.
Because multiple projects, with the same definition and resource reservations, can be active simultaneously on several different hosts, the container can conveniently manage projects across the data center. After the container has been saved, it can be used at any time to activate a project on any suitable host. Thus, the container can be used as a template for creating a new project.
The container acts as a template for multiple projects. The container stores the common properties of the projects in a central location. The common properties of the projects are the:
Project name.
The method by which the project determines which processes should be included in the project (for example, UNIX users and groups associated with the container or a match expression.)
Other properties, such as CPU share and memory limit, are specific to a host that the project is activated on. In Solaris Container Manager 3.6, this set of common properties, which is stored centrally, is called the container. When the container is activated on a specific host, it is instantiated as a Solaris project and is stored in /etc/project.
For example, a company wants to set up a container for its email applications. The common properties of the projects would be:
Project name: mail_services.
The method by which the project determines which processes should be included in the project would be a match expression containing “mozilla.”
When the container is activated on a specific host, the company instantiates the project and can now specify a resource pool, CPU shares, and memory limits.
You can use a container to create multiple projects across zones and hosts. For example, if you use a single container to create three active projects on three different hosts, you have one container and three projects in that container. Changing the underlying information in the container changes all the projects that are based on that container.
The Project Creation wizard gives you the option to create a project that is activated on completion of all the steps. A container is created at the same time and its name is saved in the GUI. You also have the option to create just the container and activate the project at a later time with a wizard that guides you through the process.
For a container, you can perform the following tasks by using the GUI:
Create a new container
Create a new group
Move the container into and out of groups
Modify the properties
Create a new project on a host
Delete the container
For a project, you can perform the following tasks by using the GUI:
Create a new group
Move the project
Modify the properties
Change the resource reservations
Create a resource change job
Check the status of the processes running inside
Request a utilization report and export the data to a file
Deactivate or activate the project
Set an alarm
Delete the project
A project does not actually enforce the resource consumption boundaries that you set for an application. Rather, after the minimum CPU reservation and memory cap are provided and the project is activated, the Solaris kernel begins enforcing these boundaries. Before using projects, you need to know more about project states. A project can be in one of the following three states: defined, active, and inactive.
A project can move between these states throughout its lifetime.
The container is created during the initial stage when the project itself is still not fully formed. Each project must have a unique name and can be saved indefinitely in the database.
Figure 3–2 shows the project moves into the active state after the container is associated with a host. An inactive project can move back into the defined state after it has been deactivated and is no longer associated with a host.
The first step in making a project active is to associate its container with a host. The second step is to set the resource boundaries, namely, to assign the minimum CPU reservation and the memory cap for the project. The project must be associated with a host that can support these resource boundaries. An active project can also be referred to as being deployed, in the sense that the project has been pushed out and resides on a host.
When creating an application-based project with the New Project Wizard, a match expression can be provided that identifies the processes associated with the application. All processes that correspond to the match expression are then automatically moved under this container. On project activation, an entry in the /etc/project database is created on the host that the container is associated with. Correspondingly, the matching processes are then moved under the project name for the container. After the processes are moved, all resource utilization data is collected and saved for the project.
When a project is deactivated, the resource boundaries are no longer enforced. A deactivated project enters into an inactive state and is deleted from the host's /etc/project file. While inactive, the project still exists in the software's database, pending future activation. After the inactive project is reactivated, the container's resource boundaries are again enforced.
All data collected about the project's use of resources while it was active is preserved in the database. You can still request utilization reports for an inactive project for up to 30 days after the project was deactivated.
Standard command-line commands in Solaris software resource management are not supported by the Container Manager software. You should manage the containers from the Container Manager graphical user interface (GUI). The GUI is started from the Java Web Console by using a browser. The following browsers are supported:
Netscape NavigatorTM 4.7x, 6.2x, and 7.x on Solaris releases 8 and 9
Netscape Navigator 4.7x, 6.2x, and 7.x on Microsoft Windows (98/2000/XP)
MozillaTM 1.4 and higher
Internet Explorer 5.0 and higher (including 6.x) on Microsoft Windows (98/2000/XP)
If your UNIX user ID is not present in the /var/opt/SUNWsymon/cfg/esusers file, create this entry.
You must also be assigned to either esadm or esdomadm group.
For instructions about creating an entry and assigning to a group, see Setting Up Users in Sun Management Center 3.6 Installation and Configuration Guide.
Start a browser.
For a list of supported browsers, see Container Manager GUI.
To reach the Container Manager GUI, type:
https://sunmc-server_machine_name:6789/containers |
The Java Web Console login page appears.
If the login page does not appear, you might need to restart Java Web Console. For instructions, see To Restart Java Web Console.
If you reach the Console page, click the Solaris Container Manager 3.6.1 link beneath the Systems section to access the GUI.
Log in to the Java Web Console by using your UNIX user ID and password.
The Container Manager GUI appears. The screen has three tabs: Hosts, Containers, and Open Alarms.
If you are unable to access the Java Web Console, use this command to restart it.
As superuser (su -), restart the Java Web Console by typing:
# /usr/sbin/smcwebserver restart |
The following table provides information about the tabs that appear in the right pane of Container Manager GUI.
Table 3–1 Container Manager GUI Tabs
Tab |
Tab Name |
Contents |
---|---|---|
Host (view) |
Contents |
Provides information about the resource pools on the selected host. |
Properties |
Provides information about the properties of the selected host, zone, project, or resource pool. |
|
Utilization |
Provides information about a host's, zone's, project's, or pool's daily, weekly, or monthly resource utilization. Real-time utilization data is available for active projects. This tab is visible only if Performance Reporting Manager software is installed. |
|
Projects |
Provides information about the projects that are associated with a host. |
|
Zones |
Provides information about the zones associated with a host. |
|
Containers (view) |
Contents |
Provides information about projects. |
Properties |
Provides information about the properties of the selected host, container, project, or resource pool. |
|
Utilization |
Provides information about a host's, zone's, project's, or pool's's daily, weekly, or monthly resource utilization. Real-time utilization data is available for active projects. This tab is visible only if Performance Reporting Manager software is installed. |
|
Jobs (Resource Change Jobs) |
Provides information about scheduled resource change jobs. You can also create a new resource change job from this tab. Note that default containers cannot have resource change jobs associated with them. |
|
Open Alarms |
Provides information about open alarms, including severity, message, managed object, start time, and acknowledgment. |
|
Resource Pool (drill down) |
Contents |
Provides information about the zones on the selected resource pool. |
Properties |
Provides information about the properties of the selected resource pool. |
|
Utilization |
Provides information about a pool's daily, weekly, or monthly resource utilization. This tab is visible only if Performance Reporting Manager software is installed. |
|
Projects |
Provides information about the projects that are associated with the selected resource pool. |
|
Zone (drill down) |
Contents |
Provides information about the projects on the selected zone. |
Properties |
Provides information about the properties of the selected zone. |
|
Utilization |
Provides information about a zone's daily, weekly, or monthly resource utilization. This tab is visible only if Performance Reporting Manager software is installed. |
|
Project (drill down) |
Properties |
Provides information about the properties of the selected project. |
Utilization |
Provides information about a project's daily, weekly, or monthly resource utilization. This tab is visible only if Performance Reporting Manager software is installed. |
|
Processes |
Provides information about the processes of the selected project. |
|
Alarm Thresholds |
Used to set or remove alarm thresholds. |
The Hosts view organizes information from the host perspective. All agent machines that you are managing appear in the navigation window. The resource pools that are available for each host are shown when you click the expansion triangle beside the host name. You can also manage the containers that are associated with the host from this view.
All agent hosts that have the software installed are automatically discovered and added to the Hosts view. This view is accessed from the left tab in the navigation window. All agent hosts that are discovered are initially placed under a default group titled Hosts. You can further organize this view by creating new groups and moving the hosts to relevant groups.
Only those agent machines that are part of the Sun Management Center server context and that have Solaris Container Manager 3.6 installed are loaded into the Hosts view. For more information about server context, see Sun Management Center Architecture in Sun Management Center 3.6.1 User’s Guide.
The tabs and information that are available in the Hosts view are listed in Table 3–1.
Information about every project instance that is associated with a host is listed in the Project table.
The following figure shows the Hosts view with the project table that is associated with the default pool.
The Project table provides information about each project, detailing one project per row. The Project table provides the following data:
Name of the project
Name of the container
State of the project: active and inactive
Resource pool to which the project is bound
Name of the zone where the project resides. For Solaris 8 and Solaris 9 hosts, the zone name is always global.
Minimum CPU shares set for the project
Amount of CPU the project is using
Maximum memory limit in megabytes
Memory used by the project in megabytes
Total amount of memory that is allowed to be used by the processes that run within this project in megabytes
The Resource Pool table provides information about each resource pool. The Resource Pool table provides the following data:
Name of the resource pool
Number of CPUs currently set for the resource pool
CPU shares that are not assigned to the zones or projects in the resource pool
Scheduler set for the resource pool: time-sharing scheduler or fair share scheduler
CPU shares set for the resource pool
Minimum number of CPUs set for the resource pool
Maximum number of CPUs set for the resource pool
The Zone table provides information about each zone. The Zone table provides the following data:
Name of the zone
State of the zone: configured, incomplete, installed, ready, running, shutting down, or down
Unique name for the zone as a virtual host
Absolute path that starts from the root (/) directory
IP address for the zone
Number of CPU shares that is allocated to the projects in the zone
Number of CPU shares available for allocation to projects associated with this zone
Number of CPU shares that is allocated to this zone in the resource pool
Resource pool for the zone
The Containers view organizes information from the container perspective. All containers and projects appear in the navigation window. Because containers can be used repeatedly to make new projects, you can readily access the containers from this view, as well as perform other management tasks.
After installation and setup are complete, the Containers view automatically adds the Containers group as a default. Containers are managed from the Containers view.
The following figure shows the Containers view.
The information that is available in the Containers view is listed in Table 3–1.
The Hosts view contains the default group Hosts. All hosts that are discovered after installation of the software are placed in this group. Likewise, the Containers view has a default group named Default in which all the default containers of a host are placed. You can create additional groups in each view for organizing the hosts and containers.
You might use groups to organize the ten or hundreds of systems you have in a data center. For example, you might put hosts located together in a group. You might put containers owned by the same customer (internal or external) or department in a group. Likewise, you might put containers with a similar application in a group.
If the Container Manager GUI is not already open, access it as described in To Start the Container Manager GUI.
Select the appropriate view from the navigation window.
For a new container group, select the Containers view. The Container table is displayed in the right pane.
For a new host group, select the Hosts view. The Hosts and Groups table is displayed in the right pane.
Click the New Group button.
A dialog box appears.
Provide a name for the group, and click OK.
The name cannot exceed 32 characters.
The new group appears in the selected view.
If the Container Manager GUI is not already open, access it as described in To Start the Container Manager GUI.
Select the appropriate view from the navigation window.
To move a container to a different group, select the Containers view. The Containers table is displayed in the right pane.
To move a host to a different group, select the Hosts view. The Hosts and Groups table is displayed in the right pane.
To enable the Move button in the table, select the check box for the container or host that is to be moved.
In the right pane, click the Move button.
A dialog box lists the available groups.
Select the group to which the container or host is to be moved.
Click OK.
The container or host is moved to the selected group.
After the software is set up, the Containers view is initially loaded with a group titled Default. This group holds the following five default containers on a host that runs the Solaris 9 or Solaris 10 Operating System (OS):
Default
Processes with No Project
Root User
System Processes
Users with Group Staff
Each of the five default containers has a corresponding entry in the /etc/project file. Specifically, the five entries correspond to default, noproject, user.root, system, and group.staff.
On a host that runs the Solaris 8 release, the Users with Group Staff (group.staff) container does not exist. Otherwise, the default containers are the same.
Each default container is in the active state, and the boundaries are set at 1 minimum CPU reservation (CPU shares) and no memory cap. A default container is always bound to the default resource pool (pool_default) of the host. You can monitor the resource utilization and run reports on each default container if you have Performance Reporting Manager installed.
These default containers cannot be deactivated, edited, or deleted. Each container is labeled Read Only accordingly.
Every UNIX user is assigned to a default project and is correspondingly assigned to a default container. Initially, the default containers hold all processes that are running on the system. As you create projects, processes are moved from the corresponding default container into the project you create.
Every project starts with a container. A project can be one of three types, depending on the project type that is selected during its creation. The project type determines how processes are tracked.
When creating a new container, you must select the project type. A project is a network-wide administrative identifier (ID) for related work. All processes that run in a container have the same project ID, and a container tracks the resources being used with the project ID. The container type is based on which project type is selected when creating the container.
Every container has a project name that is a permanent part of its information. When a container is activated on a host, this project name is added to that host's /etc/project file. This entry remains as long as the container is active on that host.
You cannot have two projects with the same project name active on a host at the same time. This is because processes that run in a container are tracked with the project ID, so every project name on a host must be unique.
When creating user-based and group-based projects, the user or group name becomes part of the project name. For user-based containers, the project name becomes user.username. For group-based containers, the project name becomes group.groupname. Therefore, when creating user-based or group-based projects, you cannot use a user name or group name that duplicates the /etc/project entries for the default containers. For more information, see Default Containers.
You provide a project name of your choosing as part of the creation process for application-based containers. The Project Creation wizard accepts duplicate project names for different application-based projects. But two application-based projects that have the same project name cannot be active on the same host at the same time. Reuse project names when creating application-based projects, only if you plan to activate these containers on different hosts. If you try to activate a second project on a host that already has a project with the identical project name, the activation fails.
The following table provides details about the three project types that are available and which changes occur based on the selection.
Table 3–2 Project Type Details
Project Type |
OS Version |
Details |
---|---|---|
User-Based |
Solaris 8 |
Only type of project supported in the Solaris 8 release. The project name in the /etc/project file becomes user.username. The project becomes the user's primary default project. |
|
Solaris 9 and Solaris 10 |
The project name in the /etc/project file becomes user.username, with a list of UNIX users who can join this project. Valid forms are username. |
Group-Based |
Solaris 9 and Solaris 10 |
The project name in the /etc/project file becomes group.groupname. Valid form is groupname. |
Application-Based |
Solaris 9 and Solaris 10 |
The project name can be the application name or any other chosen name. The name that is provided is added to the /etc/project file. A match expression can be provided for automatically moving the matching processes to the project name. This expression is case sensitive. The corresponding username or groupname under which the processes currently run must be provided. |
Before you begin using projects to manage an application's resources, you must first know the resource trends for the application. The performance of certain applications, such as ORACLE®, will be significantly degraded if the amount of the memory cap is inadequate. Every project must have resource reservations set: a minimum CPU share and optionally, a maximum memory reservation (memory cap). You should only begin using projects to manage these reservations after you have established the resource requirements for the applications.
Do not set a physical memory cap for a project that is less than what the application typically uses. This practice affects the application's performance adversely and might result in significant delays because of higher paging and swapping as the application is required to use more virtual memory.
You must have your server consolidation plan finalized before you start using projects to manage system resources. An important related task is to identify the trends in the resource consumption of the applications you include in your consolidation plan. Ideally. you identify the trends in resource utilization of the application for at least a month in your test environment before implementing your plan in your production environment. After you have established the CPU and memory consumption trends, you should allow at least a few percentage points above the typical memory requirement.
When making a reservation for the amount of CPU shares that is needed by the project, you assign the amount of CPU as an integer. For example, 25, 1, and 37 are all valid amounts. The term share is used to define a portion of the system's CPU resources that is allocated to a project. If you assign a greater number of CPU shares to a project, relative to other projects, the project receives more CPU resources from the fair share scheduler.
CPU shares are not equivalent to percentages of CPU resources. Shares are used to define the relative importance of workloads in relation to other workloads. For example, if the sales project is twice as important as the marketing project, the sales project should be assigned twice as many shares as the marketing project. The number of shares you assign is irrelevant; 2 shares for the sales project versus 1 share for the marketing project is the same as 18 shares for the sales project versus 9 shares for the marketing project. In both cases, the sales project is entitled to twice the amount of CPU as the marketing project.
CPU shares can be further broken down into two categories:
CPU shares
(Solaris 10 only) Project CPU shares (on a specific zone)
On hosts running Solaris 8 OS, one resource pool, pool_default only, is available. The pool_default has a value of 100 CPU shares.
On hosts running Solaris 9 and Solaris 10 OS, when you create a new resource pool, you establish the value of the CPU shares for the pool. Solaris Container Manager gives a default value, but you can enter any integer. Some system administrators use a formula of 100 CPU shares per CPUs available to the resource pool. For example, you might assign 100 CPU shares to a pool, which has 1 CPU.
Let's say, for this pool, you have three projects: Project X, Project Y and Project Z. You assign the most important project, Project X, 50 CPU shares and the next project, Project Y, 10 shares and the next project, Project Z, 40 shares.
You assign the CPU shares to the project when you create the project by using the New Project wizard. The New Project wizard shows the Unreserved CPU shares for the pool so you can determine the CPU shares available and assign an appropriate amount to the project.
If your host runs on the Solaris 10 Operating System, you can create zones and assign CPU shares for the zone as a whole and Project CPU shares for the projects in the zone. These are related entities.
You assign the CPU shares and Project CPU shares during zone creation by using the New Zone wizard. In Step 4 of the New Zone wizard, you select a resource pool. The wizard shows the Total CPU Shares for the pool and the Total Available CPU Shares for the pool.
You enter a value for the CPU shares that you want to allocate to this zone from the resource pool. This integer must be less than or equal to the Total Available CPU Shares for the pool.
If the pool has a Total Available CPU Shares of 100, then you can assign this zone all or some of the 100 shares. In this example, let's say we assign the zone 20 CPU shares from the resource pool.
In Step 4 of the New Zone wizard, you can also enter the Project CPU Shares. This field specifies the number of CPU shares that is allocated to projects in the zone. When you create this value, you establish the value of the Project CPU shares for the zone. You can enter any integer. The integer you enter determines the granularity you want to achieve.
For example, let's say we assign the Project CPU shares for Zone A to be 1000. On a physical level, 1000 Project CPU shares is the 20 CPU shares, inherited from the resource pool, divided into 1000 shares. Here is a formula that shows the relationship between 1 Project CPU share and CPU shares in this example:
1 Project CPU share = 20 (number of CPU shares allocated to the zone)/1000 (number of Project CPU shares) = 0.02 CPU shares
When you create a project, Project 1, in Zone A, Project 1 gets the shares from the zone and not directly from the resource pool. If Project 1 is assigned 300 shares in Zone A, then it gets 300 Project CPU shares or 300/1000 x 20/100 = 0.06 CPU shares.
You assign the Project CPU shares to the project when you invoke the New Project wizard. In Step 7 of the New Project Wizard, Provide Resource Reservations for the Project, you enter the Project CPU shares in the field labeled CPU Reservations (CPU Shares). This is true when you create a project only in a zone on a Solaris 10 host only.
When you create a project on a Solaris 8 or Solaris 9 host, the field Unreserved CPU Shares is used for entering CPU shares (not Project CPU shares).
Do not use the command line (zonecfg command) to change the CPU shares manually. This will interfere with the Solaris Container Manager calculations.
The global zone is the only zone that is not bound to only one resource pool. It can get CPU resources from any pool. Projects in the global zone can obtain CPU resources from every resource pool on the host because a hidden global zone is present in every resource pool on the host.
For example, the resource pool, Pool_default, has 4 CPUs and has zone_1 and zone_2 deployed on it. The Pool_default has 10 CPU shares. Zone_1 has 5 CPU shares, zone_2 has 4 CPU shares and the global zone has 1 CPU share.
Another resource pool, Pool_1, has 2 CPUs and has 10 CPU shares. Pool_1 has only one zone, zone_3 deployed. Zone_3 has 9 CPU shares. The global zone has 1 CPU share.
The projects in the global zone get their CPU resource from the 1 CPU share of the pool that they are deployed on.
In Solaris Container Manager, projects in the global zone must be deployed to pool_default.
Container Manager uses the fair share scheduler (FSS) to ensure the minimum CPU shares you set. The fair share scheduler is the default scheduler. The fair share scheduler calculates the proportion of CPU allocated to a project by dividing the shares for the project by the total number of active projects' shares. An active project is a project with at least one process that uses the CPU. Shares for idle projects, that is, projects with no active processes, are not used in the calculations.
For example, three projects, sales, marketing, and database, have two, one, and four shares allocated respectively. All projects are active. The CPU resources for the resource pool is distributed this way: the sales project receives to 2/7ths, the marketing project receives 1/7th, and the database project receives 4/7ths of the CPU resources. If the sales project is idle, then the marketing project receives 1/5th and the database project receives 4/5ths of the CPU resources.
Note that the fair share scheduler only limits CPU usage if there is competition for the CPU. A project that is the only active project on the system can use 100 percent of the CPU, regardless of the number of shares it holds. CPU cycles are not wasted. If a project does not use all of the CPU that it is entitled to use because it has no work to perform, the remaining CPU resources are distributed among other active processes. If a project does not have any CPU shares defined, it is assigned one share. Processes in projects with zero (0) shares are run at the lowest system priority. These processes only run when projects with nonzero shares are not using CPU resources.
The timesharing scheduler tries to provide every process relatively equal access to the available CPUs, allocating CPU time based on priority. Because the TS does not need to be administered, it is easy to use. However, the TS cannot guarantee performance to a specific application. You should use TS if CPU allocation is not required.
For example, if two projects are assigned to an FSS resource pool and they each have two shares, the number of processes that are running in those projects is irrelevant. A project can only access 50 percent of the available CPU. Thus, if one process is running the sales project and 99 processes are running in the marketing project, the one process in the sales project can access 50 percent of the CPU. The 99 processes in the marketing project must share 50 percent of the available CPU resources.
In a TS resource pool, the CPU is allocated per process. The one process in the sales project has access to only 1 percent of the CPU, while the 99 processes in the marketing project have access to 99 percent of the available CPU resources.
For more information about the fair share scheduler or the timesharing scheduler, see System Administration Guide: Network Services.
You can use Container Manager in your test environment as a tool to help trend application resource consumption by doing the following:
Installing and setting up the Container Manager software along with any required software.
For information, see Chapter 2, Container Manager Installation and Setup.
Installing Performance Reporting Manager on all agent machines you want to monitor.
For more information, see Chapter 2, Container Manager Installation and Setup and Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide.
Creating an active application-based container for the application you want to trend. In the New Creation wizard, make a minimum CPU reservation only. Do not set a memory cap.
For more information, see Creating an Application-Based Project and To Create an Application-Based Project.
Monitoring the resources used for a couple of weeks with daily, weekly, or real-time graphs. Two graphs, one for CPU and memory resources used, are available for the container that is running on an individual host. You can also view the Processes table to monitor processes running in the application.
For more information, see To Request a Resource Utilization Report for an Active Project and Viewing Project Processes.
After you have established the maximum physical memory requirement for the application, modify the container's properties to include a memory cap. Do not set a cap that is less than the maximum memory the application has been using.
For more information, see To Modify a Project Using a Property Sheet.
Setting an alarm so you are notified if the memory used starts to exceed the memory cap set. Make any adjustments to the memory cap using the Properties sheet.
For more information, see To Set an Alarm Threshold and To Modify a Project Using a Property Sheet.
After you have established resource utilization trends by using Container Manager, you can use containers to consolidate servers in your production environment.
For more information about how to plan and execute a server consolidation, you can read the Sun Blueprints book Consolidation in the Data Center by David Hornby and Ken Pepple. For more information about server consolidation on systems running the ORACLE database, you can read the Sun white paper Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software.