I haven't looked before asking this question (cardinal sin perhaps), but the thread on stand alone dump performance made me wonder if there is a performance guideline for number of page data sets. The last number i recall was minimum of 6 with no more than 2 on a volume.
Rob Schramm On Jan 7, 2014 5:37 AM, "Ron Hawkins" <[email protected]> wrote: > Rob, > > You are correct, writes are done to cache or NVS are very fast until the > "dirty cache full" threshold is hit. > > Then writes are done to cache are done very slowly. If you don't have > paging > in its own cache partition then other host writes are delayed. > > Paging IO used to be the cache IO from hell due to the track switching > designed for real DASD, and I don't know that it has changed. We can ship > 1TB of cache on a controller to avoid this situation, but it seems not too > many customers are lashing out and buying large increments like that. > > We won't get into the pros and cons of synchronous remote copy of page data > sets. It's not my dog. > > Ron > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Rob Schramm > > Sent: Monday, January 06, 2014 9:45 AM > > To: [email protected] > > Subject: Re: [IBM-MAIN] Local Page dataset sizing/quantity ROT? > > > > Does it really matter as much as it used to? The amount of cache on a > dasd > > subsystem and overall i/o seems more relevant for paging spikes. Not > that > i > > am advocating a complete dismissal of all the normal considerations.. > > but since writes are done to cache.. isn't it the foremost attribute > these > > days? > > > > Rob Schramm > > On Jan 3, 2014 4:15 PM, "Ron Hawkins" <[email protected]> wrote: > > > > > Art, > > > > > > Channels paths, ports, Front End Directors and ports are easy to map > > > so that locals can be allocated across every possible path. > > > > > > The missing part of most strategies is understanding the parallelism > > > from the cache to the disk and array group. There are many schema > > > available for RAID and wide striping, and path boundaries within the > > > storage to take advantage of (or tie you up). > > > > > > Spend some time with your vendor to understand exactly what you have > > > and how you can use it to maximize parallelism. For example on 2 > > > chassis VSP you have two separate set of disk paths behind each > > > control frame, so male sure you page datasets are spread across each > > > chassis, either by way of the HDP pool definition or the parity groups > you > > use in basic volume mode. > > > > > > Sorry for the Hitachi parlance, but it stresses the fact that you have > > > to design for the hardware you are using. An EMC methodology will not > > > be best practice for a DS8800, and an ESS methodology will not work on > an > > Hitachi. > > > > > > With the relative inactivity of page datasets, I would suggest one > > > uniform rule when tired storage is used would be to lock them into > > > tier one storage. You don't want the empty slots migrated down to SATA > > > or external storage when they suddenly get busy. > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: IBM Mainframe Discussion List > > > > [mailto:[email protected]] On Behalf Of Art Gutowski > > > > Sent: Friday, January 03, 2014 10:09 AM > > > > To: [email protected] > > > > Subject: Re: [IBM-MAIN] Local Page dataset sizing/quantity ROT? > > > > > > > > Yes, how to maximize parallelism is the pertinent question. > > > > > > > > Let's assume for the sake of argument, DS88xx with no SSD. > > > > Mix of 3390-3, -9, and -27; HiperPAV enabled, with DASD defined as > > > > SHARED in the IODF, and some shared across Sysplex boundaries > > > > (understood this > > > is > > > > not utopian, but some customers do it, either self-managed or with > > > > the assistance of MIM/MII). > > > > > > > > How do you spread that 100GB across the farm, assuming you have at > > > > least > > > > 45 mod-3 equivalents? (If my math is not too far off, there's about > > > 2.2GB of > > > > usable page space on a mod-3). What would one avoid so as not to > > > handcuff > > > > HPAV? > > > > > > > > Regards, > > > > Art Gutowski > > > > General Motors Corporation > > > > > > > > On Thu, 2 Jan 2014 08:55:24 +0100, Vernooij, CP - SPLXM > > > > <[email protected]> wrote: > > > > >I agree, overall sizing is a minor issue: make sure there is > > > > >enough, > > > what does > > > > 100GB more cost these days? > > > > >The more important issue is parallelism. Make sure ASM can do mass > > > > >page > > > > outs if it needs to. Page in should not be >your problem I suppose. > > > > >This brings in the missing info: what is your storage device? > > > > >Why don't you have Hiperpav? > > > > >The DS88xx are much more flexible than the ESSs. > > > > > > > > Kees. > > > > > > > > -------------------------------------------------------------------- > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send > > > email to > > > > [email protected] with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > > email to [email protected] with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > email > to > > [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
