The objective now that CP is not paging out the 2gb storage under dire constraints is to use the page migration from expanded storage in the most effective way.
Pages move from expanded to DASD on LRU basis - BUT only if they have been resident in Expanded for 30 seconds. So if you don't have enough storage in expanded, page migration is not effective, because pages have not been in expanded storage long enough for them to be considered for migration. Then pages are stolen from main storage straight to disk. You will find average age of pages in exstore on ESAPAGE, average age of pages migrated on ESAXSTO (in minutes). The higher then the better. And if really high, then system probably over configured anyway. I don't see much penalty with too much expanded (within reason). It is a trade off between cpu for paging to exstore if too much exstore, and penalty from writing wrong pages to disk with page steal. Your current is probably a bit high, i think in high paging situation 2gb won't be enough, but let the measurements speak. You have a fine system for performance theory testing.... >From: "Schuh, Richard" <[EMAIL PROTECTED]> >To: [email protected] > >We have been on z/VM 5.2 for 2 weeks and have seen the 2G >bottleneck = disappear as expected. We have seen an ability to >run more users as our = main benefit. We used to run into the 2G >wall with about 100 TPF guests. = We have run as many as 132 >without complaints since 5.2 was installed. = We did uncover a >latent demand for cpu time and regularly drive the = system over >85% cpu. > >Now that we have a baseline with our old configuration, we are >ready to = try to tune our storage allocations and would like >some guesstimates of = how it should be allocated. The >particulars are: > >Machine: z990 model 305 >Storage: 56GB currently allocate as 30GB main, 26GB Xstore. >Software: z/VM 5.2.0, Service level 0601+ >Workload: 90% TPF testing, up to 132 concurrent TPF machines >ranging in = size from 690MB to 2GB. These machines are driven >by CMS machines = running scripts, so they are more like batch >machines than interactive. = TPF acts more like Linux than z/OS. >=20 > >Do the two Titans of performance (or anyone else) have any ideas >about = how ought to allocate storage as our first try? =20 > >Regards, >Richard Schuh "If you can't measure it, I'm Just NOT interested!"(tm) /************************************************************/ Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, Inc Mailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.COM /************************************************************/
