Re: High CPU / channel ovhd w/3592 and DFDSS
Small blocksize maybe? Just a guess. -- 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 CPU / channel ovhd w/3592 and DFDSS
Michael, Check your HSM Activity log for msg. ADR035I, then check the Optimize value. OPTIMIZE(4) will provide you with the least amount of physical I/O. Change the DUMPIO(n) in HSM parmlib if necessary. HTH, Dave O'Brien NIH Contractor From: Michael R. Mayne [michael.ma...@hhsys.org] Sent: Wednesday, November 18, 2009 7:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: High CPU / channel ovhd w/3592 and DFDSS OK, I'll 'fess - the old tape subsystem is a 3490-A20 controller with 2 3490-B40 drive units. The old tape subsystem has hardware compression, as does the new. I'll check for software compression (never thought of it, actually), but I doubt that it's turned on. If it was, I'd expect CPU (on this box, which is a Uni) to be closer to 100% than 50%. Compression would also not explain why the CHPID utilization for the tapes is so high (and I think the CHPID utilization is directly related to the CPU overhead). Could I have them defined inefficiently somehow in my IOCDS? Am I doing bad things to tape performance with DFSMS DATACLAS or STORCLAS settings? I guess I won't know exactly what's wrong until it's fixed... Thanks. -Mike -- 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High CPU / channel ovhd w/3592 and DFDSS
This has always been a question - the DFHSM blocksize for BACKUP is (apparently) fixed at 16K, and I know of no way to override it. Any DFHSM experts out there? Thanks. -Mike -- 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 CPU / channel ovhd w/3592 and DFDSS
The answer used to be 'No' but that may have changed. Thank You, Dave O'Brien NIH Contractor From: Michael R. Mayne [michael.ma...@hhsys.org] Sent: Thursday, November 19, 2009 9:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: High CPU / channel ovhd w/3592 and DFDSS This has always been a question - the DFHSM blocksize for BACKUP is (apparently) fixed at 16K, and I know of no way to override it. Any DFHSM experts out there? Thanks. -Mike -- 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High CPU / channel ovhd w/3592 and DFDSS
Can't speak to the CPU, but the tape channel utilization may be an indication of the much higher performance tape units. Historically, many tape unit models can consume most of a channel path. The low DASD channel utilization may point to compression for that resource. Perhaps the DASD really is compressed and the tape not. That would be a simple explanation that fits your observations. HTH and good luck -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Michael R. Mayne Sent: Wednesday, November 18, 2009 2:55 PM To: IBM-MAIN@bama.ua.edu Subject: High CPU / channel ovhd w/3592 and DFDSS Our environment is a single z9-BC mainframe (2096-R07(I01)), z/OS V1R9 @ RSU0906, a 3592-C06 tape controller w/2 FX4 channels, and 3592-E05 (TS1120) tape drives. We're performing initial testing towards migrating to current tape hardware from (please don't ask, too embarrassed to tell). Using DFHSM (with DFDSS as the data mover) to back up a single 18GB sequential file (non compressed) to dual TS1120 tape drives is consuming over 50% of the total CPU. Looking at the FICON performance numbers while this is happening, I see huge (25% to 40%) utilization numbers for the 2 FX4 CHPIDS driving the tape controller, while the 2 FX4 CHPIDS connected to the DASD array are running only about 5% utilization apiece. 50% of our CPU seems (to me, anyway) to be a high price to pay to back up a single sequential file. I'm looking for (any or all of these): similar experiences, is this normal or whacked out, any tuning or performance tips that might help, how to determine exactly where the overhead is coming from, and (last but not least) how to approach IBM to address this issue. All constructive comments, questions and suggestions appreciated. Thanks. -Mike -- 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 CPU / channel ovhd w/3592 and DFDSS
Two thoughts here. 1) Your new tape drives accept data at a faster rate than your old tape drives. Therfore, you might expect that DFHSM is reading the DASD at a faster rate; hence, DFHSM gets dispatched more frequently. This would increase the apparent CPU utilization of DFHSM. However, since your backup completes in a shorter amount of time, the average CPU utilization of DFHSM should remain the same (or similar). 2) Check you HSM parameters. Use SETSYS TAPEHARDWARECOMPACT to notify DFHSM that your tape drives have this feature. And, check your SETSYS COMPACT parameter: SETSYS COMPACT(DASDMIGRATE NOTAPEMIGRATE DASDBACKUP NOTAPEBACKUP) /* USE COMPACTION FOR:*/ /*MIGRATION TO DASD */ /*BACKUPTO DASD */ /* DO NOT USE COMPACTION FOR: */ /*MIGRATION TO TAPE */ /*BACKUPTO TAPE */ You really don't need DFHSM to compact your data; the tape hardware does this for you. (Of course, if you do compact your tape backup in software, you're doing much more of this operation per second, since you are processing more data.) Of course, this may/may not be your problem; and, as always, YMMV. -- 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 CPU / channel ovhd w/3592 and DFDSS
Mike, This is definitely not normal. It might not be a bad idea to tell us what you are migrating from. We have almost the same environment as you. We have a z9-BC (G01), z/OS 1.7, 3592-C06 with 1 FX4 channel, 3592-E05 tape drives. I upgraded from 3590s to the TS1120s and our utilization on the channel to the tape drives as well as CPU utilization did not do anything even remotely close to what you're experiencing. We are doing full volume dumps to 2 tape drives simultaneously for our nightly backups. A couple ideas. Are your old tape drives so old that you have software compression turned on in DFHSM? Are you doing any kind of software-based encryption writing to these tapes? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Michael R. Mayne Sent: Wednesday, November 18, 2009 4:55 PM To: IBM-MAIN@bama.ua.edu Subject: High CPU / channel ovhd w/3592 and DFDSS Our environment is a single z9-BC mainframe (2096-R07(I01)), z/OS V1R9 @ RSU0906, a 3592-C06 tape controller w/2 FX4 channels, and 3592-E05 (TS1120) tape drives. We're performing initial testing towards migrating to current tape hardware from (please don't ask, too embarrassed to tell). Using DFHSM (with DFDSS as the data mover) to back up a single 18GB sequential file (non compressed) to dual TS1120 tape drives is consuming over 50% of the total CPU. Looking at the FICON performance numbers while this is happening, I see huge (25% to 40%) utilization numbers for the 2 FX4 CHPIDS driving the tape controller, while the 2 FX4 CHPIDS connected to the DASD array are running only about 5% utilization apiece. 50% of our CPU seems (to me, anyway) to be a high price to pay to back up a single sequential file. I'm looking for (any or all of these): similar experiences, is this normal or whacked out, any tuning or performance tips that might help, how to determine exactly where the overhead is coming from, and (last but not least) how to approach IBM to address this issue. All constructive comments, questions and suggestions appreciated. Thanks. -Mike -- 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 the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High CPU / channel ovhd w/3592 and DFDSS
OK, I'll 'fess - the old tape subsystem is a 3490-A20 controller with 2 3490-B40 drive units. The old tape subsystem has hardware compression, as does the new. I'll check for software compression (never thought of it, actually), but I doubt that it's turned on. If it was, I'd expect CPU (on this box, which is a Uni) to be closer to 100% than 50%. Compression would also not explain why the CHPID utilization for the tapes is so high (and I think the CHPID utilization is directly related to the CPU overhead). Could I have them defined inefficiently somehow in my IOCDS? Am I doing bad things to tape performance with DFSMS DATACLAS or STORCLAS settings? I guess I won't know exactly what's wrong until it's fixed... Thanks. -Mike -- 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
