Hi Ron, You are right when I changed BUFNO to 255, The overall elapsed time reduce from 12mins to 6 mins, So what can I do now,? Change BUFNO only ? How about vsam or db2 performance?
Ron hawkins <[email protected]> 於 2018年2月21日 星期三寫道： > Tommy, > > With PPRC, TrueCopy or SRDF synchronous the FICON and FCP speed are > independent of one another, but the stepped down speed elongate the Remote > IO. > > In simple terms a block that you write from the host to the P-VOL takes > 0.5ms to transfer on 16Gb FICON, and but then you do the synchronous write > on 2Gb FCP to the S-VOL it will take 4ms, or 8 times longer to transfer. > This time is in addition to command latency and round-trip delay time. As > described below, this impact will be less for long, chained writes because > of the Host/PPRC overlap. > > I'm not sure how you simulate this on your monoplex, but I assume you set > up a PPRC pair to the remote site. If you are testing with BSAM or QSAM > (like OLDGENER), then set SYSUT2 BUFNO=1 to see the single block impact. If > you are using zHPF, I think you can vary the BUFNO or NCP to get up to 255 > chained blocks. > > I'm not aware of anything in GRS that adds to remote IO disconnect time. > > Ron > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Tommy Tsui > Sent: Tuesday, February 20, 2018 2:42 AM > To: [email protected] > Subject: Re: [IBM-MAIN] DASD problem > > Hi Ron, > What happens to if our ficon card is 16gb, and fcp connection is 2gb, I > try to do the simulation on monoplex lpar , the result is fine, now we are > suspect the GRS or other system parm which will increase the disconnect time > > Ron hawkins <[email protected]> 於 2018年2月 > > 15日 星期四寫道： > > > Tommy, > > > > This should not be a surprise. The name "Synchronous Remote Copy" > > implies the overhead that you are seeing, namely the time for the > > synchronous write to the remote site. > > > > PPRC will more than double the response time of random writes because > > they the Host write to cache has the additional time of controller > > latency, round trip delay, and block transfer before the write is > > complete. On IBM and HDS (not sure with EMC) the impact is greater for > > single blocks, as chained sequential writes have some overlap between > > the host write, and the synchronous write. > > > > Some things to check: > > > > 1) Buffer Credits on ISLs between the sites. If no ISLs then settings > > on the storage host ports to cater for 30km B2B credits > > 2) Channel speed step-down - If your FICON channels are 8Gb, and the > > FCP connections are 2Gb, then PPRC writes will take up to four times > > longer to transfer. It dep[ends on the block size. > > 3) Unbalanced ISLs - ISLs do not automatically rebalance after one drops. > > The more concurrent IO there is on an ISL, the longer the transfer > > time for each PPRC write. There may be one opr more ISL that are not > > being used, while others are overloaded > > 4) Switch board connections not optimal - talk to your switch vendor > > 5) Host adapter ports connections not optimal - talk to your storage > > vendor > > 6) Sysplex tuning may identify IO that can convert from disk to > > Sysplex caching. Not my expertise, but I'm sure there are some red books. > > > > There is good information on PPRC activity in the RMF Type 78 records. > > You may want to do some analysis of these to see how transfer rates > > and PPRC write response time correlate with your DASD disconnect time. > > > > Final Comment: do you really need synchronous remote copy? If your > > company requires zero data loss, then you don't get this from > > synchronous replication alone. You must use the Critical=Yes option > > which has it's own set of risks and challenges. If you are not using > > GDPS and Hyperswap for hot failover, then synchronous is not much better > than asynchronous. > > Rolling disasters, transaction roll back, and options that turn off > > in-flight data set recovery can all see synchronous recovery time end > > up with the same RPO as Asynchronous. > > > > Ron > > > > > > > > > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Tommy Tsui > > Sent: Thursday, February 15, 2018 12:41 AM > > To: [email protected] > > Subject: Re: [IBM-MAIN] DASD problem > > > > Hi, > > The distance is around 30km, do you know any settings on sysplex > > environment such as GRS and JES2 checkpoint need to aware? > > Direct DASD via San switch to Dr site , 2GBPS interface , we check > > with vendor, they didn't find any problem on San switch or DASD, I > > suspect the system settings > > > > Alan(GMAIL)Watthey <[email protected]> 於 2018年2月15日 星期四寫道： > > > > > Tommy, > > > > > > This sounds like the PPRC links might be a bit slow or there are not > > > enough of them. > > > > > > What do you have? Direct DASD to DASD or via a single SAN switch or > > > even cascaded? What settings (Gbps) are all the interfaces running > > > at (you can ask the switch for the switch and RMF for the DASD)? > > > > > > What type of fibre are they? LX or SX? What kind of length are they? > > > > > > Any queueing? > > > > > > There are so many variables that can affect the latency. Are there > > > any of the above that you can improve on? > > > > > > I can't remember what IBM recommends but 80% sounds a little high to > me. > > > They are only used for writes (not reads). > > > > > > Regards, > > > Alan Watthey > > > > > > -----Original Message----- > > > From: Tommy Tsui [mailto:[email protected]] > > > Sent: 15 February 2018 12:15 am > > > Subject: DASD problem > > > > > > > > > > > Hi all, > > > > > > > > > Our shop found the most job elapse time prolong due to pprc > > > synchronization versus without pprc mode. It's almost 4 times faster > > > if without pprc synchronization. Is there any parameters we need to > > > tune on z/os or disk subsystem side? We found the % disk util in RMF > > > report over 80, Any help will be appreciated. Many thanks > > > > > > -------------------------------------------------------------------- > > > -- 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 > > ---------------------------------------------------------------------- > 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
