On 02/19/2013 11:25 AM, Gerhard Adam wrote:
It's really not more complicated. Higher priority work always gets the
computing cycles it needs, except as it relates to competition at the same or
higher priorities. Low priority cannot contribute any resources, since it
doesn't have anything that higher priority work needs.
In other words, work that is a dispatching priority (DP) of 255 has no higher level
competitors and therefore will only experience delays as it relates to those that are
also at DP 255. If a unit of work is at DP 240, it cannot interfere, except in the small
instance of where it may have gained control and is allowed to finish out its dispatch
cycle before being interrupted. One of the problems is that people presume that CPU
utilization reflects the overall state of the system for all units of work, which it
doesn't. CPU utilization reflects the probability that the CPU will be busy servicing
someone else when a task becomes ready. Therefore higher priority tasks "see"
a completely different utilization [i.e. probability] than low priority tasks.
If you're experiencing a problem, then it is probably related to your higher priority
work meeting its goals and therefore not requiring anything more based on your WLM
definitions. Another problem is that your higher priority work could be defined with
"impossible" goals and therefore ends up being ignored. Both of those cases
will result in your higher priority not getting any help if usage goes up.
Adam
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Natasa Savinc
Sent: Tuesday, February 19, 2013 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Low priority workload
Hello!
>From time to time (certain days in a month) we hit group or system limit. We
have different types of workload defined in WLM. Among others, most batch jobs
have the lowest priority. At the peek times they apparently get no CPU resources,
but when we make report at the end of the day, they managed to get some CPU
seconds. We would prefer that those seconds were allocated to important online
transaction.
There are two opinions amoung our sysprogs: one is that we should cancel all
low priority workload in order to help our online get all the resources, the
other is that that is not necessary, as batch isn't getting any online's CPU
resources anyway.
It seams that when you hit the limits things become more complicated.
Any thoughts about our dilemma? Any experiences with life on the edge?
Regards,
Natasa
...
In some environments with LPAR sub-capacity capping based on 4-hour MSU
average it can be more complicated.
WLM bases its management on current resources and workload. It has no
way of "knowing" that giving available resources to lower priority work
now when resources may be plentiful may result in raising the rolling
4-hour MSU average to the point that in the future the LPAR may become
capped at a time of peak load of high priority workload, denying that
later high-priority workload the ability to use any CP resources above
the MSU cap to handle short-term peaks.
It would admittedly be an unusual case where manual micro-management
might do a better job than WLM, but just be aware that on a tight
system, decisions to run lower-priority work that seem reasonable at
the time could contribute to LPAR capping during the following four
hours and adversely affect later high priority work. There could be
times when humans with better knowledge of future workloads than WLM
might be able to take preemptive action to delay or avoid LPAR capping
to improve response to future high priority workloads.
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
