In other words "It depends!" (Copyright 1985 by Bill Bitner. See http://www.vm.ibm.com/devpages/BITNER/.)
We heard a rumor at SHARE that there is magic number (something like "pag e age"?) for the age of pages in XSTORE. It "should" be between some limits. What limits? What va riable? (We have ESAMON/ESAMAP, not PerfKit.) Does that ring any bells? See also Bill Bitner's "Configuring Processor Storage - How much central vs. how much expanded." At <http://www.vm.ibm.com/perf/tips/storconf.html>: Bottom Line Recommendation Determine if your system has a 2GB storage constraint (see above). If it does not, try configuring 25% of total storage as expanded storage. Many systems do not need more t han 2GB of expanded storage regardless of the total storage available. If your system does ha ve a 2GB storage constaint, configure as expanded storage all storage that is not being effectively u sed as central storage. The number of >2G page frames on the available list is an indication of how m uch storage should be reconfigured as expanded storage. Alan Ackerman On Thu, 23 Sep 2010 10:46:54 +0200, Rob van der Heij <rvdh...@velocitysof tware.com> wrote: >On Thu, Sep 23, 2010 at 2:14 AM, O'Brien, Dennis L ><dennis.l.o'[email protected]> wrote: >> I heard from a couple of performance people at SHARE that we should ha ve 20% to 25% of the total storage in an LPAR configured as expanded storage. Naturally, th at's a guideline and the proper amount varies by workload. What should I look at to determine i f we have enough expanded storage? We use Velocity's ESALPS suite. The systems that I'm most concerned about have a Linux guest workload. One of them is all WAS, and the other is a mix of WAS, Oracle, and some other things. > >You're most welcome to send us data for review. We do that all the >time for customers. Let's work off-list on that; would be a bit unfair >to those on the list who don't have our products. > >We can tell from the data when you don't have enough expanded storage. >But you need enough performance history to know when your peak >requirement is. Too much expanded storage is rarely a problem, to >little is bad. >Expanded storage creates another layer in z/VM storage management. >Typical Linux workloads effectively bypass some of the first layers, >so you really want that last bastion before going to DASD. > >The challenge in tuning many of these workloads is that the middleware >itself introduces a layer of memory management that does not interface >with the hypervisor. The JVM grabs memory from Linux and treats it >like real, Linux gets memory from z/VM and thinks it is real. And z/VM >is trying to decide who should use the real memory and when. With no >further info from the application, z/VM uses the "what would happen >when I take this away" approach. When the page is still in expanded >storage, that works pretty well. When it went to DASD, it gets really >slow. > >So I can tell from performance data that z/VM has not enough expanded >storage. But since the tuning itself changes the workload, it is very >hard to predict how much you need (requires Crystal Ball Technology >that we have not yet announced). Since workloads change over time, and >too much expanded storage rarely hurts, I tend to stay on the safe >side. > >> I've heard that WAS isn't the best choice for System z, but that's not the focus of my concern. We have the workload that we have, and I just want to make it run as w ell as it can. >> > >Exactly my view! It's no secret you need more CPU and memory when you >replace a well-tuned CICS application by SAP with all the bells and >whistles people asked for the past 20 years. If you can even compare >the function offered. But we also get orders of magnitude more >resources in our mainframes now. Other aspects of the business justify >such a move. Can make a lot of sense. > >Rob > >-- >Rob van der Heij >Velocity Software >http://www.velocitysoftware.com/ >======================== ========================= ========== =============
