David, Perhaps with a different twist, what problems are you trying to prevent :-)
I wouldn't go to the level of Controller separation anymore - it'd s bit of overkill. However I'd still look for some level of hardware separation within the controller to ensure paging runs as fast possible when you need it. Wide striping on EMC and HDS would make separate parity groups unnecessary, but consider Tier 1 or SSD for paging as you don't want it on the lowest tier when you need it. Also separate LCU, Channels, ports, and VSD for Hitachi Storage if you can. This things will optimize the speed of paging when you need it. Size is a question of the maximum number of slots you use when you page out, usually due to a dump. You may want to go back and look at how many slots you used the last few times dumping caused you to do some serious paging and size the locals to be 4 to 10 times the maximum slots used. In MXG parlance that would mean summing MAXUSED from TYPE75 for every interval, and then a proc univariate or means to see what shakes out. The idea here is to avoid AUX slot shortages. Have fun Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jousma, David > Sent: Thursday, December 26, 2013 10:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Local Page dataset sizing/quantity ROT? > > Elardus, > > You are being a little tough on me today. Maybe your summer is too warm? > ;) > > See below > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Thursday, December 26, 2013 11:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Local Page dataset sizing/quantity ROT? > > Jousma, David wrote: > > >Hope everyone had a good holiday. > > What holiday? I don't see any holiday! ;-D ;-D ;-D ;-D >>Ouch. > > >Today we have a roughly 36GB of LOCAL page for each system, that was > setup in 2006 spread across 4 mod-9's. Back then we didn't have the amount > of memory on the processors that we have now, nor did we have DB2's using > data above the bar. Most of the systems in our sysplex have around 40Gb of > memory configured online. We have many more DB2 V10 instances active > now than we did in 2006. Without doing a lot of math and measurements, > I'm leaning towards giving each system between 80 and 100Gb's of local page > spread across 4 LOCAL page datasets for each system? We have dynamic > PAV's enabled. That would be 3-4 mod27's each. I could go with mod-54's, > at 2 per system, but not really sure how much the actual number of virtual > DASD devices even matters anymore? > > I think, you should say WHY are you asking? Performance issue? Response > time? Batch jobs doing 'query from hell'? Workload issue? Other jobs / > subsystems grabbing all memory? Anything else? > >> have the occasional job that causes problems, usually DB2 related. > > Just please define your 'system'. DB2 [sub] system or LPAR system? SysPlex? > >> 10-way parallel sysplex, 2-4 db2 subsystems on each lpar. > > For myself, I would go for 4 local page datasets distributed on at least two > different control units for DASD. Just try to spread your paging out on more > devices if you can do that. I would increase your number 4 to 8 or more if > that > is possible in your environment. > > I'm just begging one or three questions: > > What is your DB2 priority in WLM? > >> No idea > > > Do you have any response time problems? > >> Not usually, in fact we don’t page much to begin with. > > > What is your LPAR / LPARS CPU/Memory limits? This could probably raised > and thus eliminate your paging problem? > >>I listed current memory configurations in original comments. There > >>are additional memory upgrades on the way. Most lpars have about 40Gb > >>of memory configured online > > >Just trying to do the right thing. > > Probably not. ;-D It is really difficult to try to help you. I think you > should post > your actual problem you're trying to solve. > > >>not really trying to solve any problem, just making sure things are still > >>set > correctly. Maybe *I* am erroneous in thinking that local paging subsystem > needs to some factor larger than installed physical memory. > > Groete / Greetings > Elardus Engelbrecht > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any > manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message > was misdirected. After replying, please erase it from your computer system. > Your assistance in correcting this error is appreciated. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
