Tommy,
That's a really big question. You're talking about a complete batch tuning
exercise. The increased buffering is an old tuning hack, but with synchronous
replication, the primary benefit is for sequential writes where you can achieve
the Host/RIO overlap. It works equally well for the QSAM, BSAM, and VSAM.
For VSAM though, be sure it is sequential write IO, because with random NSR
VSAM adding buffers can degrade performance. The best tuning trick I've used
with replication and VBSAM random writes is to use LSR with deferred writes.
Deferring writes will stop VSAM from writing the CI every time a record is
updated, and change the writes to buffer replacement based on LSR. For truly
random updates there will only be a small benefit, but for updates and inserts
with good locality or in key order the result can be a huge reduction in
writes, and therefore the impact of remote IO. You can specify LSR with
deferred writes in JCL using AMP=('ACCBIAS=DO',' SMBDFR=Y').
DB2 database often writes after the fact, and it is the log performance that is
important to externalize harden updates and speed up batch. If you are not
using zHyperwrite, then I suggest you look at implementing that first before
anything else. zHyperwrite in simple terms is host RAID-1 for the DB2 logs, but
the storage is aware that the host is writing directly to the P-VOL and S-VOL.
It means you have to use FICON across the DWDM, stepping down to 2Gb, but at
30km the RTD is small and you should get the benefit of eliminating the RIO
from the write path.
If you are using DFSMS compression, you may want to look at turning it off for
the data sets that you think will benefit from large buffers. DFSMS compression
limits the IO data length to just one track, increasing the number of write IOs
and reducing the IO/RIO overlap.
I would suggest that you need to understand the batch critical path and use
that to identify the longest jobs and job steps to identify the tuning
opportunities where writes can be sped up or eliminated. You're looking at a
large batch tuning exercise.
Ron
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tommy Tsui
Sent: Tuesday, February 20, 2018 4:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] DASD problem
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 <ronjhawk...@sbcglobal.net> 於 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:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tommy Tsui
> Sent: Tuesday, February 20, 2018 2:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <ronjhawk...@sbcglobal.net> 於 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tommy Tsui
> > Sent: Thursday, February 15, 2018 12:41 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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 <a.watt...@gmail.com> 於 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:tommyt...@gmail.com]
> > > 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 lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > >
> > > ------------------------------------------------------------------
> > > --
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > >
> >
> > --------------------------------------------------------------------
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> >
> > --------------------------------------------------------------------
> > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO
> > IBM-MAIN
> >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
