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
