Terry,
I've been using it for around 10 months now at one of my customers and it
appears to be doing the job. Their environment experiences huge CPU spikes
during it's month end processing (4-6 days of 95-100%, where normally CPU is
around 40%). They are using Focus to produce a large number of reports from
databases with several million records in each.
Before trying VMRMSVM the operators where busy adjusting relative shares during
month end to keep the VSE nightly batch cycle from running over, while also
trying to keep the Focus machines processing to meet their deadline. We tried
various combinations of relative and absolute shares, but were never able to
get the right mix to meet everyone's deadlines. The problems were: month end
started on different days of the week (each day has it's unique processing),
the amount of data being processed varied by hundred's of thousands records,
and the mix of Focus runs would change (quarter end, year end, etc)
Getting a larger z9 or using capacity on demand (on a monthly basis) were too
costly to do, especially with the much lower utilization during the rest of the
month.
Using VMRMSVM to adjust the relative appears to help because both the VSE and
the Focus workloads are getting finished before their deadline. The operators
are no longer allowed to adjust the relative shares and I'm not getting calls
in the night about VSE or Focus jobs being too slow.
I don't profess to fully understand VMRMSVM, but here are some observations
I've found while using this:
1) Put all your zVM machines under it's control (there are some exceptions like
VMRMSVM, PERFSVM, and there could be others in your case). VMRMSVM appears to
do a better job balancing when it sees all the work not just a small group of
machines.
2) Place each of the heavy CPU machines in their own group. VMRM checks the CPU
run/wait deltas proportion of all the machines in a group. One heavy CPU
machine in a group will cause the group to exceed it's goals. VMRM then starts
adjusting the relative shares downward for all the machines in the group,
particularly the heavy CPU machine. With some of the Focus runs going for 8
hours or more I saw some relative shares of 1 which was a bit of shock. I
found I needed to have 15-20 groups altogether with 10 of those being single
machine groups
3) I used the option of being able to dynamically change configurations. I did
this to reduce the goals for the Focus processing during the nightly VSE batch
work. When the VSE work finishes, I raise the goals again.
4) It's been an iterative process of setting goals and mixing (or separating)
machines.
5) I don't normally see much, if any change in the relative share values VMRM
sets when the z9 is lightly loaded.
Ed Neidhardt
Mainline Information Systems, Inc.
770-321-0841 Office
ed.neidha...@mainline.com
- Original Message -
From: Martin, Terry R. (CMS/CTR) (CTR)
To: IBMVM@LISTSERV.UARK.EDU
Sent: Thursday, October 29, 2009 8:06 PM
Subject: VMRMSVM - z/VM Resource Manager
Hi,
I am looking at implementing VMRM. I was wondering if you use it and if it is
working as advertised? I want to mainly use it for managing the priority of my
different workloads running in z/Linux. I am familiar with the goal concept
from WLM on the z/OS side so I understand the principle behind it but I just
wanted to know from those who use it how it is working. Also any specifics on
setting it up in terms of what to watch out for etc..
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
terry.mar...@cms.hhs.gov
WFH on Tuesdays and Fridays