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
