Re: ADRDSSU performance degradation
Hi, It's because to support 256k when writing and reading a tape, adrdssu use know bsam rather than excp for dump /restore. Unfortunately, it's the default, thus to have a good throughput, you use more cpu cycle. To avoid that, code PARM='USEEXCP=YES' with DCB=BLKSIZE=65520 on the output dataset or if you wan't modify your JCL JOB, use the DSS exit (ADRUIXIT) to set the UFOPARM of UFOEXCP to ON to eliminate the need to code the parm useexcp and blksize=65520. regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU performance degradation
1) Full volume backups every 4 hours 2) no control cards were changed 3) no, maintenance was not applied to running libraries (never do that) 4) yes an IPL was done WITH CLPA (it's always done at IPL). 5) Yes maintenance was installed that affects ADRDSSU One other item, during analysis that has been found. The jump in cpu usage did not occur right away, but occurred about 24 hours after the IPL. It seems to coincide with a config change to a ISV product, that occurred around the timeframe of the cpu usage increase. We are working with that vendor to see if there's anything about that product that may be affecting the system. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU performance degradation
Here's some more info. I've got a volume, that is online to our production lpar and one of our test lpars. If I run a full volume dump on my test lpar, it uses 6.88 seconds of cpu time. If I run the job on my production lpar, it uses 20.86 cpu seconds. Using Mainview and doing a trace of where it's spending it's time, the test lpar trace shows that it is approx 62% of the samples were in IECVPST, followed by 11.7% in IAXPQ, then 10.4% in ADRDTDS, etc. On my production lpar, the order is completely different, with 39% being in IAXPN, then 34% in IAXPQ then 11% in ADRDTDS and only 8% in IECVPST. Why is it spending so much time in the IAXPN/IAXPQ modules? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU performance degradation
Ok, Finally figured out the problem. I had inadvertently left component trace for SYSRSM on, after working on debugging a SA78-18 abend. Turned it off, and we're back to normal! Yeah!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU performance degradation
On 14.05.2013 20:18, Peter Vander Woude wrote: We are running z/OS 1.11 and in prep for our upgrade to 1.13, we IPL'd last week sunday to implement the ptf's for toleration/compatibility with 1.13. In reviewing our performance last week, we are seeing large cpu time increases in programs such as ADRDSSU, where the week before the IPL, ADRDSSU used approx. 3 hours of cpu time per day. A couple days after the IPL, that jumped up to 7 hours of cpu time per day, with no real change in the # of executions. An example of the increase is a jobstep that before the IPL used approx. 12 minutes tcb time, and 7.5 minutes srb time and approx. 15 million IOPS. AFter the IPL we are now seeing the same step do the same 15 million IOPS, but TCB time has jumped to 26 minutes and SRB time has jumped to 23.5 minutes. I know that 1.11 is out of support, so i can't ask them, but does anybody have an idea on this? I did do a number of searches on ibmlink, but to no avail. Thanks, Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Never see like this, and I guess your configuration is the same as before, the only thing occured to me is that some compression and /or OPT default has changed or working in other way . Can you check the dump/backu p size ? -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ADRDSSU performance degradation
A few details might help. What are you asking ADRDSSU to do? Have any of the control cards or options changed? Did any other system options change? Have datasets run into extra extents as a result of the apply? Did you update the running system or apply the changes to an idle set of target libraries? Are you running with the new PTFs? If so, did your IPL include a CLPA? Did any of the PTFs hit ADRDSSU? :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Peter Vander Woude :: Sent: Tuesday, May 14, 2013 11:18 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: ADRDSSU performance degradation :: :: We are running z/OS 1.11 and in prep for our upgrade to 1.13, we IPL'd :: last week sunday to implement the ptf's for toleration/compatibility :: with 1.13. In reviewing our performance last week, we are seeing large :: cpu time increases in programs such as ADRDSSU, where the week before :: the IPL, ADRDSSU used approx. 3 hours of cpu time per day. A couple :: days after the IPL, that jumped up to 7 hours of cpu time per day, with :: no real change in the # of executions. :: :: An example of the increase is a jobstep that before the IPL used approx. :: 12 minutes tcb time, and 7.5 minutes srb time and approx. 15 million :: IOPS. AFter the IPL we are now seeing the same step do the same 15 :: million IOPS, but TCB time has jumped to 26 minutes and SRB time has :: jumped to 23.5 minutes. :: :: I know that 1.11 is out of support, so i can't ask them, but does :: anybody have an idea on this? I did do a number of searches on ibmlink, :: but to no avail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
