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
