Hello, I'm starting to try to use VMRM to handle "meeting our business goals". I'm trying to; 1) Prioritizing workloads/guests; "most-loved", "not as much", least , and bottom-feeders 2) setting VMRM's config file to match this above list. Hoping that the highest will get as much as it needs (within reason), following down the list, and, if the CPU resources are sufficient, all will get enough to accomplish their tasks satisfactorily. We do not use VMRM for CMM, or setting DASD velocity goals. I am testing this on a low activity system (test lpar) so the results may be shewed because due to the lack of competition for CPU resources.
The following is what I have seen about how VMRM determines when/how to adjust; A sample monitor interval of less than 1 minute or more than 5 minutes is not recommended. For CPU goals, all of the following must be true: The user has a Relative share setting. The user does not have LIMITHARD specified on the CPU SHARE setting. The user is not already within 5% of the goal for the user. The CPU velocity goal is the percentage of time that the workload should receive CPU resources when it is ready to consume them. This is computed by taking the time the users are running and dividing the sum of time the users are running or waiting for CPU. The variable target must be an integer from 1 to 100. If a user is within a reasonable percent of the target goal, they will be considered to have met the goal, and no adjustments will be made for this user – Workloads are selected first based on importance value – If a workload was selected in the last interval either for improvement or degradation, it is skipped and an attempt is made to select another – If there are workloads of equal importance, the workload farthest from its goal is selected – Eligible users within a workload will have their SHARE or IOPRIORITY adjusted appropriately based on how far they are from the workload goal • Individual users within selected workload may be adjusted based on calculations from monitor data – User must have Relative Share and I/O Priority settings – User does not have Limithard specified for CPU Share – Sum of wait and run deltas is > current sample size of 5 – Sum of I/O and Outprioritized deltas is > current sample size of 5 – CPU actual = run delta / (run delta + wait delta) * 100 – DASD actual = IO delta / (IO delta + outprior delta) * 100 • If above criteria is met and user is not within 5% of goal, then they can be adjusted How to adjust each user – relvalue = (CPU goal / actual) * User current share The current sample size of 5 is a threshold value. It used to determine if there is enough data to make decisions on for the user. For example; with monitor settings of; INTERVAL 1 MINUTES RATE 5.00 SECONDS a user would need to be active at least 5 of the 12 samples. From my testing, VMRM does not provide the results that I expected. After adjusting workloads, goals, and importance; VMRM sets relative shares for most-loved and bottom-feeders the same. My view may be tainted by past experiences with WLM on zOS, but I assume this may be due to VMRM just looking at the last interval vs a loner period for sampling. Also, I found VMRM logs and the PerfToolKit's display very lacking in helpful data in this area. Has anyone had a more positive experience with VMRM? Or am I missing something? Thanks, ----------------------------------------- Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
