Re: High DASD disconnect time due to RANDOM READ
Agreed, a 50% hit rate is pretty bad, but a heck of a lot better than zero. If you could somehow exclude the file from all caching, then I would expect a drastic degradation of I/O performance. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of jason to Sent: Tuesday, February 17, 2009 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: High DASD disconnect time due to RANDOM READ I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. Regards, Jason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
snip-- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip- In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
Rick, You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. The best cache candidates I have found are actually random IO. The first controller I used was a 3880-23 with 8MB of cache and volumes like SYSRES, Checkpoint1, MIM and RACF improved throughput radically. 350 IOPS for a controller was unheard of at that time. The success of random IO depends on the locality of reference of the IO requests. I found VSAM files with clusters of IO around particular keys - new, active customers vs old, dormant customers or some company phone numbers - get excellent benefit from cache, while databases with hashed keys like IMS Fast Path and CA-IDMS were nasty cache polluters. YMMV. Back to the Jason's original idea of excluding some IO from cache; I'm afraid you're out of luck. At bests you can use DCME with MSR in SMS to influence how some controllers will retain or discard an IO once it is in cache, but in all vendor offerings - HDS, IBM, SUN and EMC - everything must go through cache. Inhibit Cache Load and Bypass Cache do not do what they say. Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. Ron snip-- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip- In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
The purpose behind cache is to reduce the amount of time elapsed between issuing a read request and having data to process. If the data to be read is in cache because someone just read or wrote it or the controller was doing sequential read ahead, I do not care. I did not have to wait on the slow DASD to position and transfer the data. That is a valid read hit in my book. Dennis Roach GHG Corporation Lockheed Marten Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Wednesday, February 18, 2009 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: High DASD disconnect time due to RANDOM READ Rick, You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. The best cache candidates I have found are actually random IO. The first controller I used was a 3880-23 with 8MB of cache and volumes like SYSRES, Checkpoint1, MIM and RACF improved throughput radically. 350 IOPS for a controller was unheard of at that time. The success of random IO depends on the locality of reference of the IO requests. I found VSAM files with clusters of IO around particular keys - new, active customers vs old, dormant customers or some company phone numbers - get excellent benefit from cache, while databases with hashed keys like IMS Fast Path and CA-IDMS were nasty cache polluters. YMMV. Back to the Jason's original idea of excluding some IO from cache; I'm afraid you're out of luck. At bests you can use DCME with MSR in SMS to influence how some controllers will retain or discard an IO once it is in cache, but in all vendor offerings - HDS, IBM, SUN and EMC - everything must go through cache. Inhibit Cache Load and Bypass Cache do not do what they say. Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. Ron snip--- --- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip - In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
Re: High DASD disconnect time due to RANDOM READ
--snip- You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. -unsnip-- We tested with a pair of purpose-built programs, on a 3990-6 controller and again on RAMAC II and RAMAC III, and again on our SHARK box, with substantially the same kinds of results. The first program re-read the same sequential dataset, of 100 cylinders, over and over, for a total of 100 passes. While the RAMAC and SHARK tests weren't complete, 'cuz we couldn't turn off the cache, on the 3990 testing the results were stunning. Elapsed time was reduced by 65% when we enabled the cache in the 3990, and the device response time, as shown by RMF, was halved. The second program used a random-number generator to select records from a DIRECT dataset, using BDAM access. Improvement was noticeable with cache enabled, but not anywhere as surprising as the results from our sequential dataset tests. The datasets were preloaded with 100 cylinders of half-track records in both sets of tests. IEBDG was used to create records with a relative record number in the first 6 bytes, and random strings in the remainder of the record. Subsequent experience showed very good improvements in our IDMS database performance, but since we used several small areas for each database, spread across multiple volumes, locality of reference was fairly high. We actually reached a point where the IDMS CV was inhibited because it couldn't get LOG records written out fast enough. As you note, RACF and JES2 Checkpoint performance gained amazing improvements, again due to high locality of reference. -snip--- Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. -unsnip--- I'd like to see that as well. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
High DASD disconnect time due to RANDOM READ
I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. Regards, Jason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
