Re: MDC size impacted after migration to z/VM 5.4
On Wed, 11 Feb 2009 11:51:04 -0600, Brian Nielsen bniel...@sco.idaho.gov wrote: Is there anything in the transition between z/VM 5.3 SLU 0702 and z/VM 5 .4 SLU 0801 that would negatively impact MDC's use of real storage in favor of guest storage? I noticed in a recent ESAMDC report that the average size of MDC had plummeted from what it normally has been. Looking back through my historical data I see that it happened on the day and time that I migrat ed from z/VM 5.3 to z/VM 5.4 (11/30/2008). MDC is in real storage only, no ne in XSTORE. All MDCACHE parameters are the same as is the storage/xstore for the LPAR and vstor for the Linux guests. The MDC objective size has not changed in the reports and are way above the average MDC size. Page rates are still typically at or near zero, but the reported MDC Steals/s ec has gone from near zero to the 40-70 range with prolonged intervals of 2 00- 300 and some as high as 700/sec. The ESAUSR2 report shows total resident pages for guests has increased b y about the same amount as MDC storage has decreased, and it seems to be spread out across all guests, which are mostly SUSE Linux. The number o f locked pages is about the same. The number of VDISK pages in real stora ge is also about the same. The page rate to/from xstor is way down, which makes sense since the guests have more pages resident in real storage. I'm just not sure why CP is now favoring guest storage more at the expense of MDC than it used to . It doesn't appear to be an IPL related phenomenon, as the data across a prior IPL of z/VM 5.3 shows consistent behavior. If it's not a z/VM release related issue what else should I look at/for? Brian Nielsen = === We've been tracking some issues with unexpected MDC arbiter decisions tha t this may well be an example of (it has been observed that seemingly unrelated storage changes elsewhere can affect MDC arbiter behavior due t o the way the arbiter algorithm works), but there were also some APARs (VM64082 and VM64510 come to mind) that could have caused some changes, I 'll have to check in to the contents of those RSUs and get back to you later. - Bill Holder, z/VM Development, IBM Endicott
Re: MDC size impacted after migration to z/VM 5.4
On Wed, 11 Feb 2009 12:41:04 -0600, Bill Holder hold...@us.ibm.com wrot e: We've been tracking some issues with unexpected MDC arbiter decisions th at this may well be an example of (it has been observed that seemingly unrelated storage changes elsewhere can affect MDC arbiter behavior due to the way the arbiter algorithm works), but there were also some APARs (VM64082 and VM64510 come to mind) that could have caused some changes, I'll have to check in to the contents of those RSUs and get back to you later. - Bill Holder, z/VM Development, IBM Endicott = === Thanks. If you need any more data I will happily collect it. I won't try experimenting with changing any parameters yet, but if you're aware of any changes that might be beneficial or detrimental please let m e know. Brian Nielsen
Re: MDC size impacted after migration to z/VM 5.4
It doesn't look like either level (5.3.0 SLU 0702 or 5.4.0 SLU 0801) contains either APAR in question (VM64082 or VM64510), so unless you've applied them proactively, it sounds like we can rule them out. I think we're going to want to look into what's going on in a little more detail - it's possible it's an example of the issue I mentioned, but it's also possible that 5.4.0's decision might actually be a better overall tradeof f. - Bill Holder, z/VM Development, IBM Endicott
Re: MDC size impacted after migration to z/VM 5.4
On Wed, 11 Feb 2009 14:35:37 -0600, Bill Holder hold...@us.ibm.com wrot e: It doesn't look like either level (5.3.0 SLU 0702 or 5.4.0 SLU 0801) contains either APAR in question (VM64082 or VM64510), so unless you've applied them proactively, it sounds like we can rule them out. I think we're going to want to look into what's going on in a little more detail - it's possible it's an example of the issue I mentioned, but it's also possible that 5.4.0's decision might actually be a better overall tradeoff. - Bill Holder, z/VM Development, IBM Endicott I did some looking, and saw in the z/VM Performance Report under z/VM 5.4 Performance Considerations in the MDC Changes section it says that: APAR VM64082 to z/VM 5.2 and 5.3 changes the behavior of the MDC storage arbiter. Recall the arbiter's job is to determine how to proportion storage between guest frames and MDC. This APAR, rolled into the z/VM 5.4 base, is not on any z/VM 5.2 or 5.3 RSU. So VM64082 should be on my z/VM 5.4 system. I read the descriptions for both APARs and it does sound like it is my problem. I see that VM64510 is on SLU 0802, but in the meantime I may adjust my MDCACHE minimum size and/or bias values as suggested in the above referenced Performance Report section. Is there a potential that doing s o will cause problems in the other storage routine processes mentioned in the APARs? Brian Nielsen
Re: MDC size impacted after migration to z/VM 5.4
On Wed, 11 Feb 2009 15:22:56 -0600, Brian Nielsen bniel...@sco.idaho.gov wrote: ... I did some looking, and saw in the z/VM Performance Report under z/VM 5. 4 Performance Considerations in the MDC Changes section it says that: APAR VM64082 to z/VM 5.2 and 5.3 changes the behavior of the MDC storag e arbiter. Recall the arbiter's job is to determine how to proportion storage between guest frames and MDC. This APAR, rolled into the z/VM 5. 4 base, is not on any z/VM 5.2 or 5.3 RSU. So VM64082 should be on my z/VM 5.4 system. I read the descriptions for both APARs and it does sound like it is my problem. I see that VM64510 is on SLU 0802, but in the meantime I may adjust my MDCACHE minimum size and/or bias values as suggested in the above referenced Performance Report section. Is there a potential that doing so will cause problems in the other storage routine processes mentioned in the APARs? Brian Nielsen = === I'm sorry I missed that, I forgot to check if VM64082 was in the 5.4.0 ba se, but that does sound right, I knew that at one point, now that I think abo ut it. You definitely do want to get and apply VM64510, then, and see how t hat affects things. In the meantime, yes, you do want to adjust your setting s. As long as you don't exceed the values you were typically seeing on 5.3. 0, that shouldn't affect other processes appreciably. - Bill Holder, z/VM Development, IBM Endicott
