HP 3000 Manuals

Planning Workgroups [ Using the HP 3000 Workload Manager ] MPE/iX 5.0 Documentation

Using the HP 3000 Workload Manager

Planning Workgroups

To use the Workload Manager effectively, you need to know who uses your
system now, how they use it, and how to translate this information into
an effective workgroup configuration. In this section, you'll find
questions and suggestions to help you gather this data.

To evaluate current system use

Knowledge of the current system workload is essential to the effective
use of the Workload Manager. As system manager, you should be familiar
with the demands of all your users and clearly understand the relative
priorities of these demands.

The questions below can help you gain a more complete understanding of
who uses the system and what their needs are. Consider these questions
as a guideline only. Other questions, more pertinent to your particular
situation, will arise while you are gathering information.

* What kinds of on-line users need the system? Begin by
categorizing users by job title or function, for example, data
entry clerks, customer service representatives, system analysts,
or programmers.

* What system needs does each group of users have? For example, do
some of the users interact directly with customers and therefore
require fast response time?

* Do you have a Service Level Agreement (SLA) with a specific
department or division within your company that you must meet?

* Is there an identifiable pattern of system use over time for each
group? For example, at the end of each quarter, do your financial
analysts place a heavy demand on the system to prepare fiscal
reports? Or is there a peak demand for database access between 9
o'clock and noon and again between 2 and 5 o'clock?

* How and when are batch jobs submitted on your system and do any of
them require a guaranteed turnaround time? For example, does your
Marketing staff run a report every morning that must be on the
CEO's desk by 10 a.m.?

To partition the system workload into workgroups

Once you understand who is using the system and what their needs are, you
can determine how to group the users effectively. For example, you might
create separate groups for data entry clerks, all batch jobs updating a
certain database, one particular batch job, application developers using
editing programs, or special servers. It is these logical groupings that
you translate into workgroups.

Suppose you wanted to begin by creating three user-defined workgroups,
one for a server, one for data entry clerks who log orders for retail
products, and one for programmers who are editing their application
files. The workgroup membership criteria might look like this:

Table 2-1. A Set of Sample Workgroups

Once you decide what workgroups you want, the next step is to determine
the appropriate workgroup order and what kind of access to the CPU each
workgroup will have (explained next). It is important to understand,
however, that the first workgroup configuration you devise is unlikely to
be the last. Developing workgroups with the appropriate membership
criteria and scheduling characteristics is an iterative process. You
should anticipate continual monitoring of the existing workgroup
configuration, evaluation of system performance, and at least some
ongoing modification.

To understand the importance of workgroup order

The workgroups on your system are maintained in an ordered list, which is
identical to the order in which workgroups are listed in any indirect
file used by the NEWWG command. You determine workgroup order by:

* Creating and/or editing the indirect file.

* Adding new workgroups to the current configuration.

* Removing a workgroup from the current configuration.

When the Workload Manager assigns a process to a workgroup, it uses a
"first-fit algorithm". That is, the Workload Manager searches the list
of workgroups on your system and places the process into the first
workgroup in which it fits. It does not seek a "best fit".

Both the membership criteria that you do specify, and those that you
don't specify, affect the placement of processes in a workgroup. That's
because if you omit a category, the Workload Manager treats it as a match
when it is determining membership. (For example, to allow a process with
any logon potentially to become a member of a workgroup, don't specify
MEMB_LOGON= when you create the workgroup.) In general, to capture a
broader population of processes, specify fewer membership criteria.

In light of these factors, it is important that you order workgroups so
that those with the most specific membership criteria appear first and
those with more general membership criteria follow. The five
system-defined workgroups, which only specify a single criterion,
MEMB_QUEUE, always appear last in the list of workgroups.

How workgroup membership is determined: an example

Listed below are the names and membership criteria for three user-defined
workgroups and the five default system-defined workgroups. (These are
not intended to be realistic or complete workgroup specifications, since
the point of this example is to understand workgroup membership.)

WORKGROUP=Program_Development
;MEMB_PROGRAM=(EDITOR.PUB.SYS, QEDIT.@.@, HPEDIT.@.@)
;MEMB_LOGON=(@.TEST, "NM@,@.MYTEST")

WORKGROUP=Payroll_Online
;MEMB_PROGRAM=(PAYROLL.@.PRAPP)
;MEMB_QUEUE=(CS)

WORKGROUP=Payroll_Batch
;MEMB_PROGRAM=(PAYROLL.@.PRAPP)
;MEMB_QUEUE=(DS,ES)

WORKGROUP=AS_Default
;MEMB_QUEUE=(AS)

WORKGROUP=BS_Default
;MEMB_QUEUE=(BS)

WORKGROUP=CS_Default
;MEMB_QUEUE=(CS)

WORKGROUP=DS_Default
;MEMB_QUEUE=(DS)

WORKGROUP=ES_Default
;MEMB_QUEUE=(ES)

Based on the preceding membership specifications, processes are assigned
to the workgroups as shown in the following table.

To help you understand this example, consider why process 100 is assigned
to the Program_Development workgroup and process 200 to the CS_Default
workgroup. Both processes have the same queue attribute, and both meet
the logon requirement for Program_Development. The critical difference
is that process 200 is executing EDITOR from the MYTEST account, whereas
the Program_Development workgroup requires that EDITOR come from PUB.SYS.

To find the workgroup for which Process 200 does qualify, proceed down
the ordered list. Process 200 fails to match the program criterion for
Payroll_Online and the queue criterion for Payroll_Batch, AS_Default, and
BS_Default. The first workgroup in which Process 200 does fit is
CS_Default, and, as a result, that is its destination.

To establish workgroup scheduling characteristics

The workgroup membership criteria determine which processes are grouped
together in a particular workgroup, while the scheduling characteristics
control the CPU access of those processes. You use your knowledge of the
needs and relative priorities of these workgroups to establish the
scheduling characteristics.

When you first create workgroups, consider setting only the required
scheduling characteristics of base and limit priority, allowing all other
values to assume their defaults. Then, monitor system performance and
make the necessary adjustments, using the following list of guidelines to
help you.

* Give higher base and limit priorities to more important
workgroups.

* Assign overlapping priority ranges to workgroups that have similar
needs.

* Adjust quantum bounds to provide the proper rate of priority
decay.

* To allow workgroups with long-running transactions to compete with
shorter transactions, do one of the following: set the boost
property to OSCILLATE, increase the timeslice value, or increase
the minimum CPU percentage of the workgroup.

If you need to review the function and use of any of the traditional
scheduling parameters, read the next section. It explains each of them
in detail, as well as describing the new CPU percentage bounds.

An Overview of Scheduling Characteristics

With Release 5.0, the MPE/iX Dispatcher remains priority-driven,
dispatching processes to the CPU(s) based on their priority. The MPE/iX
Scheduler controls process priorities in accordance with the scheduling
parameters established by the system manager. The scheduling
characteristics include those characteristics associated with traditional
scheduling subqueues, as well as new CPU percentage bounds that are
available for user-defined workgroups.

Base and Limit Priorities.

The base and limit priorities determine the range of priorities available
to processes within the workgroup. If no user-defined workgroups have
CPU percentage minimums, the CPU will be allocated to processes based on
their priorities. For example, processes in a workgroup with base=152
and limit=160 will run before processes in a workgroup with base=170 and
limit=180. (Note, however, that the priorities you assign to workgroups
can overlap, so that processes within the workgroups compete with each
other for the CPU.)

For base and limit, priority is inversely related to the integer value:
a higher-priority process has a lower number. Processes in the
CS_Default, DS_Default, and ES_Default system-defined workgroups, and all
processes in any user-defined workgroups, begin execution at the base
priority and decay toward the limit priority. At some point, depending
upon the boost property set for the workgroup, any process that is not
yet complete is boosted back to the base priority to continue execution.

In traditional MPE/iX parlance, the CS, DS, and ES scheduling subqueues
were known as "circular scheduling queues" because their process'
priority circulated within the bounds of the established base and limit
values for the subqueue. For example, a process in the CS subqueue will
start at the base priority of 152 and decay towards the limit of 200.
This behavior has not changed for the three system-defined workgroups
which corresponding to the CS, DS, and ES subqueues.

NOTE The introduction of workgroups dictated a simplification of the
preemption algorithm. Because the assumption that a higher
subqueue indicates a more important process is no longer valid, the
dependency on scheduling queue attribute was eliminated. The
algorithm continues to compare priorities, only considering
preemption if the priority of the potential preemptor exceeds the
priority of the running process by the preemption threshold. If
system and boosted processes are able to pass these priority
checks, they can preempt the running process (if it is
preemptable).

Quantum Bounds.

The minimum and maximum quantum values bound the calculation of the
workgroup quantum, which determines the rate of priority decay of
processes within the workgroup. The quantum represents the average
transaction time of processes within that workgroup. The consumption of
CPU by a process is compared against the quantum to determine the amount
of priority decay. Small quantum values mean most transactions are
short, and process priorities will decay quickly. Larger quantum values
indicate longer transaction times, and process priorities will decay more
slowly.

NOTE All three system-defined workgroups that have decayable processes,
the CS_Default, DS_Default and ES_Default workgroups, now perform a
dynamic quantum calculation using a similar decay algorithm. The
algorithm bases priority decay on the quantum divided by a
constant, applying smaller amounts of priority decay for smaller
amounts of CPU consumption.

The default values for the minimum and maximum quantum for the
DS_Default and ES_Default workgroups have remained the same to
ensure that the quantum will not vary unless you choose to change
the bounds. The traditional DS and ES subqueues did not provide
this flexibility and had a fixed quantum value.

Boost Property.

While the quantum controls the rate of priority decay, the boost property
determines the behavior of the process once its priority has decayed to
the limit of the workgroup. The default value of DECAY indicates that
the process will decay to the limit and remain there until it completes
its transaction. The value OSCILLATE indicates that if the process
priority decays to the limit of the workgroup, its priority is reset to
the base priority (the process oscillates between the base and limit
priorities).

Timeslice.

The timeslice is used to ensure that one process does not monopolize the
CPU for long periods of time. When a process is launched, the Dispatcher
guarantees that it will not run for more than its timeslice value (even
if it is CPU-bound). The Dispatcher will actually take the CPU away from
the process if it is still running after the timeslice interval has
passed (provided that the process can be interrupted).

NOTE Before Release 5.0 of MPE/iX, CS subqueue processes were able to
preempt DS or ES subqueue processes since they had a higher
subqueue, and thus the timeslice values for the DS and ES subqueue
were set high. These default values have now been reduced so that
processes in these workgroups cannot monopolize the CPU for long
periods of time. The timeslice value remains tuneable, however,
and the system manager can adjust it to a higher value if it is
appropriate to the environment.

CPU Percentage Bounds.

User-defined workgroups also allow the specification of minimum and
maximum CPU percentage bounds. The minimum percentage serves as a
guarantee. Processes in a workgroup with minimum CPU percentage equal to
20% will be guaranteed 20% of the CPU(s), provided they have enough
demand to use the 20%. If the processes demand more than 20%, they can
receive more, providing it does not violate the minimum values for other
workgroups. Thus, the minimum is a true minimum and can be exceeded. It
is not a target amount.

The maximum percentage serves to restrict the CPU consumption of a
workgroup. Processes in a workgroup with a maximum CPU percentage equal
to 50% will never receive more than 50% of the CPU. If no other
workgroups require CPU, the system will idle rather than allow the
workgroup to exceed its maximum.

The sum of all CPU minimums should not exceed the amount necessary to
provide sufficient "leftover" CPU for the system processes. As an
alternative to guaranteeing a minimum to workgroups, the system manager
might choose to set a maximum CPU percentage on a workgroup that tends to
starve other workgroups. The maximum will constrain the workgroup to run
within the allocated amount of CPU.

MPE/iX 5.0 Documentation