From my experience on systems with limited CPs (albeit some time ago):
- Velocities need to be reviewed. Achievable velocities might be much
lower than on a system with more CPs.
- It is critical that goals are achievable. The goal tells WLM when it
can take resources away from high importance work to allow lower
importance work to run. If high importance work isn't achieving its
velocity goal, WLM will not allow lower importance work to take CPU time
from higher importance work.
- Related to the previous point, it is better to under specify
velocities than over specify. Specify the minimum velocity required to
complete the work in time.
- I had good success with multi period batch service classes. This
allowed small lower importance jobs (small enough that they wouldn't
significantly impact more important work) to complete while the
important work was prioritized over larger jobs.
- Multi period service classes made response time goals practical for
the first periods and reduced the need to figure out velocities.
- Discretionary worked great for batch work *BUT* you need to have
enough work running in discretionary. If you have e.g. 5% of work in
discretionary it's likely to get starved. If it's 20-30% i.e. your CPU
intensive batch, it will run and simplify WLM management - WLM knows
exactly where the CPU resources should come from to handle workload
fluctuations.
- WLM also had a function where it would cap higher importance work that
was over achieving goals to allocate more CPU to discretionary. This
helped control high importance, CPU intensive work that WLM had
difficulty managing with dispatching priorities. I think there have been
changes in this area so I don't know whether this is still applicable.
I think my service classes for batch ended up something like:
Low importance batch:
Period 1: Long enough for small jobs to complete, response time goal.
Period 2: Discretionary
High Importance Batch:
Period 1: Small jobs, response time goal
Period 2: Most other work response time or velocity goal (can't remember)
Period 3: Monsters, discretionary.
This worked well.
High importance batch jobs in discretionary is a bit controversial, but
it worked great for me on a system with limited CPs. I don't know why
(maybe the MTTW dispatching in discretionary?) but when I implemented it
the overnight batch run time reduced 15-20%.
I hope this helps,
Andrew Rowley
On 31/01/2020 1:23 am, Pesce, Andy wrote:
I have recently replace an IBM-2828 that had 5 GP's to a newer model machine
IBM-3907-ZR1 with only 2 GP's.
Does anyone know of a guide or paper or something that might have some things
to look at or modify when reducing the number of GP's.
I have 2 classes of service for my batch jobs. One runs with a velocity and importance
of "2". This is a grouping we have called our
critical path jobs that are time sensitive and they must run. Then I have another
class that runs with a velocity, but has an importance of "3".
This grouping is for jobs that are not time sensitive, but they do need to run
and get service.
The behavior that I am seeing is that the class that has the IMP-2 dominates
the box until they are finished. The other jobs will sit in the
initiator for 30mins up to an hour and I never see any service being consumed.
Then once the IMP-2 jobs finish, then the other jobs
will take off and get service.
My goal is to have the IMP-2 take 80-90%, but give the IMP-3 a small chunk of
service. The only way that I have been able to come close
is to make both classes the same importance level.
Any thoughts, documents, white papers, experiences with dealing with the
reduction of GP's would be greatly appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
