In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on 01/23/2012 at 09:08 AM, "Staller, Allan" <allan.stal...@kbmg.com> said:
>From the viewpoint of the Operating System, you now >have 3 times as much data behind the actuator on Mod-9's as Mod-3's. >If the Operating system *thinks* the device is busy, the IO is queued >off the UCB and never even tried until it comes to head of queue. You MIGHT have up to three times as much data behind the actuator. That depends on how fully loaded the three mod-3s are which are to be merged onto the same single mod-9; i.e., it depends on which three mod-3s you choose to merge together. If all data sets on all volumes are equally and randomly accessed, then you will have three times as much requirement to access the new mod-9 as any of the three mod-3s had which were merged. However, most data centers have highly skewed access patterns. 80% of the actuators might have only 20% of the total I/O workload. Which means your volumes are almost certainly NOT equally and randomly accessed. You have some volumes that are almost never accessed and some others that are accessed all the time. When z/OS starts in I/O on DASD device xxxx, z/OS turns on a flag bit in the UCB for that device that indicates that this particular z/OS image has started an I/O on that device. But if the device is shared, then another z/OS image may have already started an I/O on the same device, turned that same device's UCB flag bit on in its copy of the UCB for the device (which might be device yyyy on the other image), and not informed any of the other sharing z/OS images that it is now doing I/O on that shared device. So when image A tests its private copy of the flag bit and finds it off, that does not necessarily mean that the device is unbusy. Image A doesn't care, however. It starts the I/O and turns the bit on. If the shared control unit attached to this device is not an IBM 2105 SHARK (vintage ca. 2000), plug-compatible equivalent, or some successor technology, then image A's I/O will not really be started until image B's already started I/O ends. This will show up on ima! ge A as a spike in device pending time, not in IOSQ time. The 2105 and newer technology have the ability to let multiple I/O requests from multiple sharing systems run simultaneously against the same device as long as there is no conflict between any of the simultaneous I/Os involving both reads and writes for the same range of tracks. The only way to know what will probably happen is to do I/O measurement on your current mod-3 workload. If you don't see much IOSQ time now, then you will see "not much" multiplied by three after merging. How much is not much and/or is negligible is up to you to decide. You might also get an idea as to how to merge volumes together based on their individual IOSQ times; e.g., merge the one with the highest IOSQ time now with the two mod-3s that now have the lowest average IOSQ times. After merging them, measure again for IOSQ time. Only if you have "excessive" IOSQ time, where how much is excessive is up to you to decide, would you need to consider using PAV devices. Currently z/OS's I/O Supervisor has no knowledge of the real RAID architecture backing the virtual SLED, so many of the classic performance- and space-related bottlenecks can theoretically still occur. Bill Fairchild ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
