Jump to content English
hp.com home
HP Global Workload Manager (gWLM)  |  Getting the most out of gWLM

Getting the most out of gWLM

  HP Global Workload Manager (gWLM)

»gWLM concepts / overview
Getting the most out of gWLM
»Getting Started - gWLM Home
»Manage New Systems (Create SRDs)
»Manage Workloads
»Unmanage Workloads
»Edit SRDs
»Edit Policies
»Edit Workloads
»Edit Associations
»Configure Events
»View Summaries
»View Real-time Reports
»View Historical Reports
»Set Up Read-only Monitoring
»Web browser tips
»Tab: Shared Resource Domains
»Tab: Policies
»Tab: Workloads
»Tab: Associations
Content starts here

This help page explains how to set up your environment and then implement gWLM to get the most benefit from gWLM.

gWLM allows you to decrease the number of CPUs needed on a server while increasing utilization of the remaining CPUs. gWLM best optimizes CPU utilization in an environment where CPU resources can be borrowed (moved between workloads). The following sections suggest ways you can maximize the amount of CPU resources that can be borrowed:

» Setting up npars to maximize resource sharing (npar requirements)
» Setting up vpars to maximize resource sharing
» Setting up SRDs to maximize resource sharing
» Setting up OwnBorrow policies to maximize resource sharing

Setting up npars to maximize resource sharing (npar requirements)

Using the HP product Instant Capacity, gWLM simulates the movement of CPUs between npars by turning off an active CPU in one npar then turning on a deactivated CPU in another npar in the same complex. Thus, the first npar has one less active CPU, while the second npar has one additional active CPU. (gWLM maintains the number of active CPUs, honoring the Instant Capacity licensing limits. As a result, no costs are incurred.)

When setting up npars to be managed by gWLM:

  • Each npar must have the HP product Instant Capacity installed and running

  • Each npar must have the following property set to 'on' in the file /etc/opt/gwlm/conf/gwlmagent.properties:


  • Each npar must not be divided into virtual partitions

In addition, while you can create an SRD with a single npar, gWLM can only simulate CPU movement when there are at least two npars.

gWLM can adjust an npar's CPU count:

  • Up

    By as many inactive CPUs as it has--assuming there are just as many active CPUs in the other npars in the SRD that can be deactivated

  • Down

    To its compartment minimum

Setting up vpars to maximize resource sharing

When setting up your HP-UX virtual partitions (vpars), you can increase the number of CPUs that can be borrowed by setting the:

  • Minimum number of CPUs for the vpar to one

  • Number of bound CPUs for the vpar to one

To maximize the number of CPUs a vpar can borrow, set the vpar's maximum number of CPUs to a large number.

Setting up SRDs to maximize resource sharing

In defining your SRDs, you can increase the amount of CPU resources that can be borrowed by:

  • Creating bigger SRDs, with more workloads and more resources

    For example, if you have a single-cell nPartition (with four CPUs), you may only be able to host two vpars. There can be some borrowing, but it would be limited. However, with a two-cell nPartition (with eight CPUs), you may be able to host four or five vpars, each with its own workload. With the additional workloads, it is much more likely that at least one workload is idle. Busy workloads can then borrow CPUs from the idle workload.

  • Mixing critical and less-critical workloads

    Combining important workloads that need immediate CPU access wastes resources as it forces you to set aside CPU resources so that each workload can meet its peak demand at the same time. Alternatively, you can combine both critical and less-critical workloads. You would still set aside CPU resources for the critical workloads. However, you would set aside fewer resources for the less-critical workloads, relying on their being able to borrow resources from critical workloads that are not at peak demand--as is often the case because demands on workloads are staggered.

  • Mixing workloads that run at different times

    Combining workloads that run at different times, such as a highly user-interactive workload that runs during the day and a noninteractive batch job that runs at night, frees up resources for sharing to other workloads that may be running.

Setting up OwnBorrow policies to maximize resource sharing

When defining OwnBorrow policies, there are a number of parameters that affect how resources are shared:

  • Minimum CPU resources

    The value you specify for a policy's minimum CPU is guaranteed and is not shared with other workloads. Setting these values as low as possible makes more CPU resources available for sharing. For npar, vpar, and pset compartments, the lowest minimum you can specify is one CPU. For compartments based on fss groups, you can specify values less than one CPU. However, be sure to give fss-group compartments enough CPU resources so that the workloads can get started.

  • Owned CPU resources

    Set the amount of a policy's owned CPU resources according to how critical the workloads are that will use the policy:

    • Critical workloads

      Set the owned CPU resources to meet peak demand for critical workloads.

      For workloads that have a high business value (and for which high latency would have an adverse business impact), such as most production workloads, set the owned CPU resources so that the workloads' performances are acceptable under peak demand.

    • Less-critical workloads

      Set the owned CPU resources to meet minimum requirements for less-critical workloads, relying on borrowing for additional resources.

      These workloads have lower business values and infrequent periods of minor latency would not be as detrimental to the business. Typically, test and development workloads fall into this category. If they get all the resources they need most of the time, but may occasionally get less, the impact on the business is negligible. These workloads need to be guaranteed enough resources for some minimally acceptable performance, but can rely on borrowing resources to meet their remaining needs.

    As stated earlier, combining multiple workloads of both types in an SRD helps ensure CPU resources are available for borrowing when needed.

  • Maximum CPU resources

    The larger a maximum value you specify, the more resources a workload can borrow. Set these values to the total number of CPUs on the server--or a value between Owned CPUs and the total CPU count if you want to limit a workload's CPU access.