Re: Tape performance (was: Re: Preferred TSM Platform)
Alex Paschal apasc...@msiinet.com writes: [...] Have a look at the 'fcstat' command recently introduced into AIX. This will output an unpleasant bunch of data, but some nice scripting can isolate the FC SCSI Traffic Input Bytes and Output Bytes lines for the desired HBA, even if the HBA doesn't have disk on it. A loop, fcstat | grep | awk, sleep , and a subtraction will give you bytes/second numbers. Heck, it'll even give you cool stuff like IP over FC bytes if you use it. Cute. IBM: Please, make the command work on the JS21 (1st generation blades), too! Currently it's not operational there - surely that's because of the QLOGIC HBAs. We happened to get a bunch of (4-way) JS21s, and (given fast FC disks) they make for surprisingly speedy TSM servers, likely because of their CPU horsepower. As regards basic tape I/O statistics: In 'topas', the Readch/Writech values (upper right corner) have always included tape I/O. Served me well enough in the past ... - Wolfgang J Moeller @ GWDG (who had to help IBM adapt the _TSM_device_drivers_ to the QLOGIC HBA :-)
Re: Tape performance (was: Re: Preferred TSM Platform)
Need your advice. I had a scheduled monthly archive for a file server, data stored direct to tape LTO4 with total size approx. 900GB, and it takes 26 hours! I had try using NT backup for the same object, and it's just take 10 hours. What's wrong with this TSM-tape performance? The aggregate rate is just 10MB/s. My TSM server is Wind 2003 R2 SP2, TSM Client Win 2003 R2 SP2, LANFree. Best Regards, Yudi Darmadi PT Niagaprima Paramitra Jl. KH Ahmad Dahlan No.25 Kebayoran Baru, Jakarta Selatan 12130 Phone: 021-72799949; Fax: 021-72799950; Mobile: 081905530830 http://www.niagaprima.com - Original Message - From: Marcel Anthonijsz marcel.anthoni...@gmail.com To: ADSM-L@VM.MARIST.EDU Sent: Saturday, February 28, 2009 3:03 PM Subject: Re: [ADSM-L] Tape performance (was: Re: Preferred TSM Platform) I wrote a small script to collect the snmp data from the Brocade fibre switches and put the data into Servergraph. Next I created a report to graph the data and in that way we could see historical data throughput and identified more than once a faulty tape drive! You definitely want to monitor your tape throughput! For fiber-attached tape drives - use snmp to monitor the fiber switch ports. I use mrtg to acquire the data from my two tape-oriented SAN switches; this feeds my hobbit (renaming, currently, to xymon) monitoring package. I get to see the activity for each tape drive (one per switch port) and for each TSM HBA (one per switch port - zoned to all tape drives, run as one primary and 4 alternates per switch). Marcel
Re: Tape performance (was: Re: Preferred TSM Platform)
And on this one . . . Have you tried nmone with ^ ? And what is the fcstat command in? AIX? Not in my man pages and find doesn't show fcstat. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 7:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) Rick Saylor wrote: Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Thanks, Rick! I was still running nmon 11e and didn't have this new option (and I'm still at 5.3 TL8... at TL9 nmon is bundled in with topas). Once I upgraded to 12e, the '^' key does indeed show all the HBAs. Also thanks to Stef Coene, Alex Paschal and Richard Cowen for pointers to fcstat, a tool I wasn't aware of that falls in the dead simple or obvious category. :) Wonder why the IBMers and business partner tech folks weren't aware of it either. -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu mccg.org email firewall made the following annotation CONFIDENTIALITY NOTICE: The information transmitted in this e-mail message, including any attachments, is for the sole use of the intended recipient(s) or entity to which it is addressed and may contain confidential, privileged and/or proprietary information. Any unauthorized review, retransmission, use, disclosure, dissemination or other use of,or taking any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail, or by calling (478) 633-7272, and destroy the original message, attachments and all copies thereof on all computers and in any other form. Thank you. The Medical Center Of Central Georgia. http://www.mccg.org/ 03/02/09, 09:52:48
Re: Tape performance (was: Re: Preferred TSM Platform)
The fcstat was introduced in AIX 5.3. It is included in the devices.common.IBM.fc.rte fileset. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Wallace.Dwight Sent: Monday, March 02, 2009 7:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) And on this one . . . Have you tried nmone with ^ ? And what is the fcstat command in? AIX? Not in my man pages and find doesn't show fcstat. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 7:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) Rick Saylor wrote: Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Thanks, Rick! I was still running nmon 11e and didn't have this new option (and I'm still at 5.3 TL8... at TL9 nmon is bundled in with topas). Once I upgraded to 12e, the '^' key does indeed show all the HBAs. Also thanks to Stef Coene, Alex Paschal and Richard Cowen for pointers to fcstat, a tool I wasn't aware of that falls in the dead simple or obvious category. :) Wonder why the IBMers and business partner tech folks weren't aware of it either. -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu mccg.org email firewall made the following annotation CONFIDENTIALITY NOTICE: The information transmitted in this e-mail message, including any attachments, is for the sole use of the intended recipient(s) or entity to which it is addressed and may contain confidential, privileged and/or proprietary information. Any unauthorized review, retransmission, use, disclosure, dissemination or other use of,or taking any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail, or by calling (478) 633-7272, and destroy the original message, attachments and all copies thereof on all computers and in any other form. Thank you. The Medical Center Of Central Georgia. http://www.mccg.org/ 03/02/09, 09:52:48
Re: Tape performance (was: Re: Preferred TSM Platform)
To be exact fcstat was introduced in AIX 5.3 @ TL05. Regards, Kamran Rao -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of James Choate Sent: March 2, 2009 10:06 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Tape performance (was: Re: Preferred TSM Platform) The fcstat was introduced in AIX 5.3. It is included in the devices.common.IBM.fc.rte fileset. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Wallace.Dwight Sent: Monday, March 02, 2009 7:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) And on this one . . . Have you tried nmone with ^ ? And what is the fcstat command in? AIX? Not in my man pages and find doesn't show fcstat. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 7:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) Rick Saylor wrote: Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Thanks, Rick! I was still running nmon 11e and didn't have this new option (and I'm still at 5.3 TL8... at TL9 nmon is bundled in with topas). Once I upgraded to 12e, the '^' key does indeed show all the HBAs. Also thanks to Stef Coene, Alex Paschal and Richard Cowen for pointers to fcstat, a tool I wasn't aware of that falls in the dead simple or obvious category. :) Wonder why the IBMers and business partner tech folks weren't aware of it either. -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu mccg.org email firewall made the following annotation CONFIDENTIALITY NOTICE: The information transmitted in this e-mail message, including any attachments, is for the sole use of the intended recipient(s) or entity to which it is addressed and may contain confidential, privileged and/or proprietary information. Any unauthorized review, retransmission, use, disclosure, dissemination or other use of,or taking any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail, or by calling (478) 633-7272, and destroy the original message, attachments and all copies thereof on all computers and in any other form. Thank you. The Medical Center Of Central Georgia. http://www.mccg.org/ 03/02/09, 09:52:48
Re: Tape performance (was: Re: Preferred TSM Platform)
We are not on 12e with nmon. We are at 11e. I just saw an email that said the fcstat came with 5.3 TL05 -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Wallace.Dwight Sent: Monday, March 02, 2009 9:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) And on this one . . . Have you tried nmone with ^ ? And what is the fcstat command in? AIX? Not in my man pages and find doesn't show fcstat. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 7:25 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Tape performance (was: Re: Preferred TSM Platform) Rick Saylor wrote: Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Thanks, Rick! I was still running nmon 11e and didn't have this new option (and I'm still at 5.3 TL8... at TL9 nmon is bundled in with topas). Once I upgraded to 12e, the '^' key does indeed show all the HBAs. Also thanks to Stef Coene, Alex Paschal and Richard Cowen for pointers to fcstat, a tool I wasn't aware of that falls in the dead simple or obvious category. :) Wonder why the IBMers and business partner tech folks weren't aware of it either. -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu mccg.org email firewall made the following annotation CONFIDENTIALITY NOTICE: The information transmitted in this e-mail message, including any attachments, is for the sole use of the intended recipient(s) or entity to which it is addressed and may contain confidential, privileged and/or proprietary information. Any unauthorized review, retransmission, use, disclosure, dissemination or other use of,or taking any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail, or by calling (478) 633-7272, and destroy the original message, attachments and all copies thereof on all computers and in any other form. Thank you. The Medical Center Of Central Georgia. http://www.mccg.org/ 03/02/09, 09:52:48
Re: Tape performance (was: Re: Preferred TSM Platform)
I wrote a small script to collect the snmp data from the Brocade fibre switches and put the data into Servergraph. Next I created a report to graph the data and in that way we could see historical data throughput and identified more than once a faulty tape drive! You definitely want to monitor your tape throughput! For fiber-attached tape drives - use snmp to monitor the fiber switch ports. I use mrtg to acquire the data from my two tape-oriented SAN switches; this feeds my hobbit (renaming, currently, to xymon) monitoring package. I get to see the activity for each tape drive (one per switch port) and for each TSM HBA (one per switch port - zoned to all tape drives, run as one primary and 4 alternates per switch). Marcel
Re: Tape performance (was: Re: Preferred TSM Platform)
An interesting source of tape drive performance data is the TSM server itself, in the SUMMARY table. Extract it with SELECT into a comma-delimited or tab-delimited file, and then read it in to any popular statistical program like SPSS or SAS. You have to match up the records for processes such as MIGRATION, RECLAMATION, MOVE DATA... with the corresponding TAPE MOUNT records to track it down to the individual drive, but that's not rocket science in a stat program. Subtract media wait time, and you've got pretty good tape drive performance informaiton. Every day, I have a cron process that extracts the previous day's SUMMARY data into a file. But for exploration, you could simply extract the entire 30-days SUMMARY table into a file and then work that over with SAS or SPSS to get some very intersting stats. This is, of course, measuring only end-to-end tape subsystem speed. There is no way to separate out the bus, controllers, the drives, etc. But since you are collecting all of it, rather than spot anecdotal measurements, and since you do have specific drive names in the data, it gains quite a bit of statistical validity. You can also correlate the data with what kind of operation it is e.g. migration, reclamation, move data, client backup, etc. A distinct advantage is that it requires no instrumentation other than the TSM server itself, so you can get this data in brain-dead systems like Windows just fine. Another distinct advantage of this data source is that it's measuring it where it really matters - how much data TSM actually can push through that pathway. Therefore it's easy to track whether changes such as splitting drives out among multiple controllers, helps or not. P.S. I like AIX systems for TSM servers too. The best server system for large data I/O throughput. If you don't use AIX, you'll find yourself splitting servers much earlier, and into far more small pieces. Roger Deschner University of Illinois at Chicago rog...@uic.edu == If you torture the data long enough, they will confess. === On Fri, 27 Feb 2009, David Bronder wrote: Wanda Prather wrote: And there is NO instrumentation in Windows to give you any idea whatever about what is going on performance-wise on a bus with tape drives attached. Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). (Speaking only of FC drives, since the last time I used SCSI tape drives years ago, I never tried to get that data.) So far, neither IBMers nor business partners I've talked to have been able to identify a way of collecting that kind of data, either. The best ideas I've been able to come up with are manual timing tests (measure the time to transfer a known volume of data, whether within TSM or externally) or to look at stats on the fibre ports on the SAN switches (assuming one has that kind of access to the switches). If anyone can tell me differently, I'd love to hear about it. Even if (especially if?) it's something dead simple or obvious that I've been missing. =Dave (sticking with AIX for TSM for the forseeable future) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
Tape performance (was: Re: Preferred TSM Platform)
Wanda Prather wrote: And there is NO instrumentation in Windows to give you any idea whatever about what is going on performance-wise on a bus with tape drives attached. Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). (Speaking only of FC drives, since the last time I used SCSI tape drives years ago, I never tried to get that data.) So far, neither IBMers nor business partners I've talked to have been able to identify a way of collecting that kind of data, either. The best ideas I've been able to come up with are manual timing tests (measure the time to transfer a known volume of data, whether within TSM or externally) or to look at stats on the fibre ports on the SAN switches (assuming one has that kind of access to the switches). If anyone can tell me differently, I'd love to hear about it. Even if (especially if?) it's something dead simple or obvious that I've been missing. =Dave (sticking with AIX for TSM for the forseeable future) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
Re: Tape performance (was: Re: Preferred TSM Platform)
On Friday 27 February 2009, David Bronder wrote: Wanda Prather wrote: And there is NO instrumentation in Windows to give you any idea whatever about what is going on performance-wise on a bus with tape drives attached. Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). (Speaking only of FC drives, since the last time I used SCSI tape drives years ago, I never tried to get that data.) So far, neither IBMers nor business partners I've talked to have been able to identify a way of collecting that kind of data, either. The best ideas I've been able to come up with are manual timing tests (measure the time to transfer a known volume of data, whether within TSM or externally) or to look at stats on the fibre ports on the SAN switches (assuming one has that kind of access to the switches). If anyone can tell me differently, I'd love to hear about it. Even if (especially if?) it's something dead simple or obvious that I've been missing. The problem is that the numbers are not available. Don't ask me why. What I do is starting nmon. With 'a' you can see the adapter stats. With 'V' you van see the volume group stats. The difference is tape drive I/O. Stef
Re: Tape performance (was: Re: Preferred TSM Platform)
Stef Coene wrote: On Friday 27 February 2009, David Bronder wrote: Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). The problem is that the numbers are not available. Don't ask me why. What I do is starting nmon. With 'a' you can see the adapter stats. With 'V' you van see the volume group stats. The difference is tape drive I/O. In my environment, at least, only fibre HBAs with disk connected to them appear in the nmon 'a'dapter screen, so my HBAs dedicated to tape drives are not listed. With 8 HBAs, 2 for LUNs and 6 for tape drives, I only see the 2 used for disk (oddly, fscsi0 and fscsi1, plus fcs1 but not fcs0) and the planar SAS adapter for the system disks. So, unless you have disk and tape mixed on the same adapter (which I've always been told was contrary to best practices), I still don't see a way to get those numbers out of AIX (directly or derived). Or is nmon lying about what adapters it's reporting on? (nmon and iostat also don't cleanly deal with the multiple paths to LUNs as implemented by EMC PowerPath, so some of the stats can't be taken at face value for disks, either. nmon has support for SDD, of course. :) ) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
Re: Tape performance (was: Re: Preferred TSM Platform)
On Friday 27 February 2009, David Bronder wrote: In my environment, at least, only fibre HBAs with disk connected to them appear in the nmon 'a'dapter screen, so my HBAs dedicated to tape drives are not listed. With 8 HBAs, 2 for LUNs and 6 for tape drives, I only see the 2 used for disk (oddly, fscsi0 and fscsi1, plus fcs1 but not fcs0) and the planar SAS adapter for the system disks. Indeed, I just checked it on an AIX box with a tape-dedicated fiber card. So, unless you have disk and tape mixed on the same adapter (which I've always been told was contrary to best practices), I still don't see a way to get those numbers out of AIX (directly or derived). Or is nmon lying about what adapters it's reporting on? fcstat can show statistics, so in theory, nmon can have the same numbers. I will try to contact Nigel about this. Stef
Re: Tape performance (was: Re: Preferred TSM Platform)
Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Rick Saylor Austin Community College At 04:59 AM 2/27/2009, you wrote: Stef Coene wrote: On Friday 27 February 2009, David Bronder wrote: Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). The problem is that the numbers are not available. Don't ask me why. What I do is starting nmon. With 'a' you can see the adapter stats. With 'V' you van see the volume group stats. The difference is tape drive I/O. In my environment, at least, only fibre HBAs with disk connected to them appear in the nmon 'a'dapter screen, so my HBAs dedicated to tape drives are not listed. With 8 HBAs, 2 for LUNs and 6 for tape drives, I only see the 2 used for disk (oddly, fscsi0 and fscsi1, plus fcs1 but not fcs0) and the planar SAS adapter for the system disks. So, unless you have disk and tape mixed on the same adapter (which I've always been told was contrary to best practices), I still don't see a way to get those numbers out of AIX (directly or derived). Or is nmon lying about what adapters it's reporting on? (nmon and iostat also don't cleanly deal with the multiple paths to LUNs as implemented by EMC PowerPath, so some of the stats can't be taken at face value for disks, either. nmon has support for SDD, of course. :) ) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
Re: Tape performance (was: Re: Preferred TSM Platform)
For fiber-attached tape drives - use snmp to monitor the fiber switch ports. I use mrtg to acquire the data from my two tape-oriented SAN switches; this feeds my hobbit (renaming, currently, to xymon) monitoring package. I get to see the activity for each tape drive (one per switch port) and for each TSM HBA (one per switch port - zoned to all tape drives, run as one primary and 4 alternates per switch). The resulting graphs show that my fifth adapter to either switch from TSM us idle about 50% of the time, peaks at 400 MB/sec, and runs at a fairly steady 200 MB/sec during my peak tape activity time. I'm running 10 LTO-4 and 6 LTO-2 in a 3584 library -- 16 drives, 10 HBAs from TSM -- and it looks like I'm getting my money's worth. Tom Kauffman NIBCO, Inc -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 3:34 AM To: ADSM-L@VM.MARIST.EDU Subject: Tape performance (was: Re: Preferred TSM Platform) Wanda Prather wrote: And there is NO instrumentation in Windows to give you any idea whatever about what is going on performance-wise on a bus with tape drives attached. Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). (Speaking only of FC drives, since the last time I used SCSI tape drives years ago, I never tried to get that data.) So far, neither IBMers nor business partners I've talked to have been able to identify a way of collecting that kind of data, either. The best ideas I've been able to come up with are manual timing tests (measure the time to transfer a known volume of data, whether within TSM or externally) or to look at stats on the fibre ports on the SAN switches (assuming one has that kind of access to the switches). If anyone can tell me differently, I'd love to hear about it. Even if (especially if?) it's something dead simple or obvious that I've been missing. =Dave (sticking with AIX for TSM for the forseeable future) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
Re: Tape performance (was: Re: Preferred TSM Platform)
Hello, David. Have a look at the 'fcstat' command recently introduced into AIX. This will output an unpleasant bunch of data, but some nice scripting can isolate the FC SCSI Traffic Input Bytes and Output Bytes lines for the desired HBA, even if the HBA doesn't have disk on it. A loop, fcstat | grep | awk, sleep , and a subtraction will give you bytes/second numbers. Heck, it'll even give you cool stuff like IP over FC bytes if you use it. Alex Paschal Storage Solutions Engineer MSI Systems Integrators Your Business. Better. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David Bronder Sent: Friday, February 27, 2009 12:34 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Tape performance (was: Re: Preferred TSM Platform) Wanda Prather wrote: And there is NO instrumentation in Windows to give you any idea whatever about what is going on performance-wise on a bus with tape drives attached. Unfortunately, there doesn't seem to be any real instrumentation in AIX about tape drive performance, either. None of the standard AIX tools seem to give tape-related information (e.g. iostat or nmon), either for the tape drives themselves or for the buses or adapters the drives are connected to (unless there is also disk behind those buses or adapters). (Speaking only of FC drives, since the last time I used SCSI tape drives years ago, I never tried to get that data.) So far, neither IBMers nor business partners I've talked to have been able to identify a way of collecting that kind of data, either. The best ideas I've been able to come up with are manual timing tests (measure the time to transfer a known volume of data, whether within TSM or externally) or to look at stats on the fibre ports on the SAN switches (assuming one has that kind of access to the switches). If anyone can tell me differently, I'd love to hear about it. Even if (especially if?) it's something dead simple or obvious that I've been missing. =Dave (sticking with AIX for TSM for the forseeable future) -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.
Re: Tape performance (was: Re: Preferred TSM Platform)
Rick Saylor wrote: Instead of selecting 'a' on nmon try '^' instead. This will give you the FC adapter stats from fcstat. At least it does on version 12e of nmon. Thanks, Rick! I was still running nmon 11e and didn't have this new option (and I'm still at 5.3 TL8... at TL9 nmon is bundled in with topas). Once I upgraded to 12e, the '^' key does indeed show all the HBAs. Also thanks to Stef Coene, Alex Paschal and Richard Cowen for pointers to fcstat, a tool I wasn't aware of that falls in the dead simple or obvious category. :) Wonder why the IBMers and business partner tech folks weren't aware of it either. -- Hello World.David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bron...@uiowa.edu
NDMP TAPE Performance
We are looking to move from NFS and CIFS backup to NDMP. As such we will purchase FC's for the Filer's and connect through a 1GB SAN. We will run TSM 5.2.2 on AIX 5.2. We use 3590H, which provides 14MB/Sec and 60GB/Tape Native. We will configure our Filer volumes at 1TB. To be honest I am still not convinced with NDMP, despite CIFS being atrocious throughput. Has anyone information on the following. 1) What is the compression ratio per 3590H tape? The volume could contain 500K files. 2) If the 1TB Volume only contains say 500GB, does it store 1TB to tape? 3) How long would it take to backup and restore the above volume, with and without TOC enabled. 4) When NDMP back's up a file does it store contiguous on the tape? Because there is potential for many tape mounts to restore one file. Any other performance data and consideration is most welcome. Kind Regards Mike
Re: NDMP TAPE Performance
We've looked at this but decided on nfs/cifs backups as ndmp backups go to storage pools with type NETAPPDUMP, which you can't reclaim, copy (offsite), etc, etc. Also, i suspect tsm doesn't support DAR (direct access restore - a somewhat controversial ndmp feature :-) which allows you to restore part of a netapp volume (from somewhere in the directory tree). nfs over GBE is ok ito throughput. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wiggan Sent: 11 February 2004 14:20 To: [EMAIL PROTECTED] Subject: NDMP TAPE Performance We are looking to move from NFS and CIFS backup to NDMP. As such we will purchase FC's for the Filer's and connect through a 1GB SAN. We will run TSM 5.2.2 on AIX 5.2. We use 3590H, which provides 14MB/Sec and 60GB/Tape Native. We will configure our Filer volumes at 1TB. To be honest I am still not convinced with NDMP, despite CIFS being atrocious throughput. Has anyone information on the following. 1) What is the compression ratio per 3590H tape? The volume could contain 500K files. 2) If the 1TB Volume only contains say 500GB, does it store 1TB to tape? 3) How long would it take to backup and restore the above volume, with and without TOC enabled. 4) When NDMP back's up a file does it store contiguous on the tape? Because there is potential for many tape mounts to restore one file. Any other performance data and consideration is most welcome. Kind Regards Mike
Re: Tape performance
Usually I prefer to test using a large precompressed (zip/tar.gz) file and not to disable compression. This is closer to the reality eliminating possible (with low chance) problems due to different settings. It also helps to reveal the expand after compression issues. Pipe the output of tar+gzip to a large enough file and perform the `dd`-test again. I was able to fully load up to two FC-attached LTO-1 drives from a single system with or without compression. Maybe to utilize successfully several LTO-2 drives would be a real challenge :-() Zlatko Krastev IT Consultant Richard Sims [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 22.07.2003 22:19 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Tape performance I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. The test to move data from the operating system was just a 10GB file, although it was all zero's. ... Thanks, that extra info helps a lot... The T9840B FICON Tape Drive Specifications that I see on the vendor web site quote Performance, native 19 MB/sec. I thought the 32 MB/s was a high number. I suspect that you did not disable tape drive compression in your all-zero's test, and so ended up with a number which was a great test of your FC, but not the drive-media. In context, your ~16 MB/s TSM speed seems excellent, then. I'd be happy with that number. Customers who also have 9840B drives might want to chime in on their experiences. Richard Sims, BU
Re: Tape performance
Thanks to all who responded. We will try testing with this process also to see difference it shows in our performance tests. Brenda |-+ | | Zlatko Krastev | | | [EMAIL PROTECTED]| | | ET | | || | | 07/29/2003 07:17 | | | AM | | | Please respond to| | | ADSM: Dist Stor | | | Manager | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Tape performance | --| Usually I prefer to test using a large precompressed (zip/tar.gz) file and not to disable compression. This is closer to the reality eliminating possible (with low chance) problems due to different settings. It also helps to reveal the expand after compression issues. Pipe the output of tar+gzip to a large enough file and perform the `dd`-test again. I was able to fully load up to two FC-attached LTO-1 drives from a single system with or without compression. Maybe to utilize successfully several LTO-2 drives would be a real challenge :-() Zlatko Krastev IT Consultant Richard Sims [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 22.07.2003 22:19 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Tape performance I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. The test to move data from the operating system was just a 10GB file, although it was all zero's. ... Thanks, that extra info helps a lot... The T9840B FICON Tape Drive Specifications that I see on the vendor web site quote Performance, native 19 MB/sec. I thought the 32 MB/s was a high number. I suspect that you did not disable tape drive compression in your all-zero's test, and so ended up with a number which was a great test of your FC, but not the drive-media. In context, your ~16 MB/s TSM speed seems excellent, then. I'd be happy with that number. Customers who also have 9840B drives might want to chime in on their experiences. Richard Sims, BU
Re: Tape performance
Remember that tar cmd writes only 10k bytes and dd cmd you gave 256k. So, tar cmd can give the impression of poor performance. Also, FC address could be another factor when used as sigle with mig from disk to tape. My 2 cents... Gus [EMAIL PROTECTED] 07/22/03 02:41PM The test to move data from the operating system was just a 10GB file, although it was all zero's. The tape performance on TSM was achieved by doing a disk to tape. We took the ratings from doing a backup storagepool to tape. We tried it with storagepools that had filesystems and databases, the results are fairly close to the same. Our disk is on the SAN so we do not go through the network. Here are results from some new tests we just performed today. (Our drives are 9840B) DD Test with CBN and RMT drivers # mt -f /dev/rmt/6cbn status StorageTek 9840B tape drive: sense key(0x6)= Unit Attention residual= 0 retries= 0 file no= 0 block no= 0 # time dd if=/dev/zero of=/dev/rmt/6cbn bs=256k count=4 4+0 records in 4+0 records out RESULT: 38.78 MB/Sec real4m24.29s user0m0.17s sys 1m13.05s # time dd if=/dev/zero of=/dev/rmt/15mt bs=256k count=4 4+0 records in 4+0 records out real5m15.57s user0m0.19s sys 1m50.37s # RESULT: 32.5 MB/Sec Here is a core file used to test performance, with 453 MBytes, it take average of 2.2 minutes... # time tar -cvf /dev/rmt/14mt core a core 453736K real2m22.37s user0m0.44s sys 0m28.28s # time tar -cvf /dev/rmt/14mt core a core 453736K real2m19.16s user0m0.25s sys 0m28.79s |-+ | | Richard Sims | | | [EMAIL PROTECTED] | | || | | 07/22/2003 12:23 | | | PM | | | Please respond to| | | ADSM: Dist Stor | | | Manager | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Tape performance | --| I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. My environment is: TSM 5.7.0 on Solaris 8 Server: Sunfire 880 Tape drives are 9840 Fibre attached. As a result, we are questioning the value of putting in the more expensive tape drives when we can't seem to pump the data through as expected. Any ideas of what I might look at would be appreciated. Now, why did you not tell us what the test was? :-) Perspective and context is everything when trying to respond to postings. You very much did the right thing in getting isolated benchmark numbers first. Was the test a single, very large file so as to keep database updating out of the picture, rather than many small files? Was the client co-resident on the server system as to keep network contention out of the picture? All them factors. Richard Sims, BU
Tape performance
I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. My environment is: TSM 5.7.0 on Solaris 8 Server: Sunfire 880 Tape drives are 9840 Fibre attached. As a result, we are questioning the value of putting in the more expensive tape drives when we can't seem to pump the data through as expected. Any ideas of what I might look at would be appreciated. Thanks, Brenda Collins ING
Re: Tape performance
I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. My environment is: TSM 5.7.0 on Solaris 8 Server: Sunfire 880 Tape drives are 9840 Fibre attached. As a result, we are questioning the value of putting in the more expensive tape drives when we can't seem to pump the data through as expected. Any ideas of what I might look at would be appreciated. Now, why did you not tell us what the test was? :-) Perspective and context is everything when trying to respond to postings. You very much did the right thing in getting isolated benchmark numbers first. Was the test a single, very large file so as to keep database updating out of the picture, rather than many small files? Was the client co-resident on the server system as to keep network contention out of the picture? All them factors. Richard Sims, BU
Re: Tape performance
The test to move data from the operating system was just a 10GB file, although it was all zero's. The tape performance on TSM was achieved by doing a disk to tape. We took the ratings from doing a backup storagepool to tape. We tried it with storagepools that had filesystems and databases, the results are fairly close to the same. Our disk is on the SAN so we do not go through the network. Here are results from some new tests we just performed today. (Our drives are 9840B) DD Test with CBN and RMT drivers # mt -f /dev/rmt/6cbn status StorageTek 9840B tape drive: sense key(0x6)= Unit Attention residual= 0 retries= 0 file no= 0 block no= 0 # time dd if=/dev/zero of=/dev/rmt/6cbn bs=256k count=4 4+0 records in 4+0 records out RESULT: 38.78 MB/Sec real4m24.29s user0m0.17s sys 1m13.05s # time dd if=/dev/zero of=/dev/rmt/15mt bs=256k count=4 4+0 records in 4+0 records out real5m15.57s user0m0.19s sys 1m50.37s # RESULT: 32.5 MB/Sec Here is a core file used to test performance, with 453 MBytes, it take average of 2.2 minutes... # time tar -cvf /dev/rmt/14mt core a core 453736K real2m22.37s user0m0.44s sys 0m28.28s # time tar -cvf /dev/rmt/14mt core a core 453736K real2m19.16s user0m0.25s sys 0m28.79s |-+ | | Richard Sims | | | [EMAIL PROTECTED] | | || | | 07/22/2003 12:23 | | | PM | | | Please respond to| | | ADSM: Dist Stor | | | Manager | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Tape performance | --| I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. My environment is: TSM 5.7.0 on Solaris 8 Server: Sunfire 880 Tape drives are 9840 Fibre attached. As a result, we are questioning the value of putting in the more expensive tape drives when we can't seem to pump the data through as expected. Any ideas of what I might look at would be appreciated. Now, why did you not tell us what the test was? :-) Perspective and context is everything when trying to respond to postings. You very much did the right thing in getting isolated benchmark numbers first. Was the test a single, very large file so as to keep database updating out of the picture, rather than many small files? Was the client co-resident on the server system as to keep network contention out of the picture? All them factors. Richard Sims, BU
Re: Tape performance
I am wondering if there is something in TSM that throttles the tape performance we should be getting. I can do a dd test from the operating system to the tape drive and with that receive 2 GB per minute (32 MB/sec) but when I do a test through TSM, I only get 1 GB per minute. The test to move data from the operating system was just a 10GB file, although it was all zero's. ... Thanks, that extra info helps a lot... The T9840B FICON Tape Drive Specifications that I see on the vendor web site quote Performance, native 19 MB/sec. I thought the 32 MB/s was a high number. I suspect that you did not disable tape drive compression in your all-zero's test, and so ended up with a number which was a great test of your FC, but not the drive-media. In context, your ~16 MB/s TSM speed seems excellent, then. I'd be happy with that number. Customers who also have 9840B drives might want to chime in on their experiences. Richard Sims, BU
LTO Fibre tape performance under AIX 5.1
Greetings, We are installing a new TSM server on a pSeries 650 using TSM 5.1.6.5, and a 3584 Tape Library with a L32 and D32 frames with 15 LTO Gen 1 Tape drives. The 650 has 4 2Gb/sec FC ports; two go one McData Spherion 4500 switch, and to go to another. Half the tape drives are go to one Spherion switch, and half to the other. We have them zoned so that each FC adapter can only see 3 or 4 drives. Our problem is that we can't get the LTO performance where it belongs. A typical backup from the 650 itself using shared memory (or not) only gets 5-6 MB/Sec. About the same for a Giga-bit network AIX client with no other load. Even a MOVE DATA tape-to-tape maxes out at 8 MB/sec. In this test, we made sure the two tape drives involved were on different FC adapters, on different Spherion switches, and the 650 was otherwise idle, so there should have been no contention anywhere. It took 45 minutes to copy 21GB. Not very good. The 3584 firmware is v3060, the 3580 firmware is v3481, both the latest. The 650, the 6228 (FC adapter) microcodes are also the latest. The problem seems to be the same for all the drives. We have bumped up the dsmserv.opt options to appropriately high levels according to the Performance Guide. We think we have not overlooked anything there. Any suggestions certainly appreciated. John Schneider *** * John D. Schneider Email: [EMAIL PROTECTED] * Phone: 636-492-0247 * Lowery Systems, Inc. * 1329 Horan Disclaimer: Opinions expressed here are * Fenton, MO 63026 mine and mine alone. ***
[Fwd: LTO Fibre tape performance under AIX 5.1]
As a followup to my earlier message, one issue that came up is the TSM database and logs are on the same disks. In other words, we have the first copy of the database and the log on one disk, and the database mirror and log mirror on another disk. They are all using separate filesystems. I don't think this will perform well, but the system admin that set up the system insists on them that way because he doesn't want to use the root volume group to hold the logs (the system only has 4 drives today, two for rootvg, and two for TSM stuff). In a few weeks we are supposed to be getting some SSA drives, but have to make do until then. Would having a 9GB database and 1GB log on the same disk cause inordinate seek times? The server is in test now, with only a couple clients on it, so they are only a few percent utilized. John Original Message Subject: LTO Fibre tape performance under AIX 5.1 Date: Mon, 16 Jun 2003 13:42:10 -0500 From: John Schneider [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: ADSM: Dist Stor Manager [EMAIL PROTECTED] Greetings, We are installing a new TSM server on a pSeries 650 using TSM 5.1.6.5, and a 3584 Tape Library with a L32 and D32 frames with 15 LTO Gen 1 Tape drives. The 650 has 4 2Gb/sec FC ports; two go one McData Spherion 4500 switch, and to go to another. Half the tape drives are go to one Spherion switch, and half to the other. We have them zoned so that each FC adapter can only see 3 or 4 drives. Our problem is that we can't get the LTO performance where it belongs. A typical backup from the 650 itself using shared memory (or not) only gets 5-6 MB/Sec. About the same for a Giga-bit network AIX client with no other load. Even a MOVE DATA tape-to-tape maxes out at 8 MB/sec. In this test, we made sure the two tape drives involved were on different FC adapters, on different Spherion switches, and the 650 was otherwise idle, so there should have been no contention anywhere. It took 45 minutes to copy 21GB. Not very good. The 3584 firmware is v3060, the 3580 firmware is v3481, both the latest. The 650, the 6228 (FC adapter) microcodes are also the latest. The problem seems to be the same for all the drives. We have bumped up the dsmserv.opt options to appropriately high levels according to the Performance Guide. We think we have not overlooked anything there. Any suggestions certainly appreciated. John Schneider *** * John D. Schneider Email: [EMAIL PROTECTED] * Phone: 636-492-0247 * Lowery Systems, Inc. * 1329 Horan Disclaimer: Opinions expressed here are * Fenton, MO 63026 mine and mine alone. *** -- John Schneider *** * John D. Schneider Email: [EMAIL PROTECTED] * Phone: 636-492-0247 * Lowery Systems, Inc. * 1329 Horan Disclaimer: Opinions expressed here are * Fenton, MO 63026 mine and mine alone. ***
Re: LTO Fibre tape performance under AIX 5.1
We are installing a new TSM server on a pSeries 650 using TSM 5.1.6.5, and a 3584 Tape Library with a L32 and D32 frames with 15 LTO Gen 1 Tape drives. The 650 has 4 2Gb/sec FC ports; two go one McData Spherion 4500 switch, and to go to another. Half the tape drives are go to one Spherion switch, and half to the other. We have them zoned so that each FC adapter can only see 3 or 4 drives. Our problem is that we can't get the LTO performance where it belongs. A typical backup from the 650 itself using shared memory (or not) only gets 5-6 MB/Sec. About the same for a Giga-bit network AIX client with no other load. Even a MOVE DATA tape-to-tape maxes out at 8 MB/sec. In this test, we made sure the two tape drives involved were on different FC adapters, on different Spherion switches, and the 650 was otherwise idle, so there should have been no contention anywhere. It took 45 minutes to copy 21GB. Not very good. The 3584 firmware is v3060, the 3580 firmware is v3481, both the latest. The 650, the 6228 (FC adapter) microcodes are also the latest. The problem seems to be the same for all the drives. We have bumped up the dsmserv.opt options to appropriately high levels according to the Performance Guide. We think we have not overlooked anything there. Your posting doesn't make note of it, but we had an extensive List discussion of LTO performance at the end of last week. Your typical backup rates look like those in the chart on page 12 of ftp://ftp.software.ibm.com/software/tivoli/whitepapers/wp-tsm-lto.pdf . You don't specify what server options you boosted, but observe what the paper has to say about TXN* options. I would, however, expect your in-server operations to proceed faster. You don't say if you performed essential pre-TSM-usage benchmark tests, outside of TSM, to gather baseline numbers before using the drives under TSM in validating their performance thusly first: I would do that. You may have path serialization issues. Richard Sims, BU
Re: Slow tape to tape performance
Firstly I must ask people to accept my apologisies if this message doesn't look right This is first time I have tried to post a message hear :-) Just reading through a scenario posted by Michael Wheelock about slow tape to tape perforance... There are lots of considerations here to take note of... We run with an P660-6M1 (near enough a similar server) with a 3584 attached to four HVD SCSI LTO Drives and four FC LTO Drives (over a SAN). Each SCSI drive is attached directly to its own SCSI card in the server to max the performance. With the FC drives we can see all four over each of the four FC adapters in the server. You need to make sure you use the as few drives on one FC bus as possible... + fcs1 51-08 FC Adapter * fscsi151-08-01 FC SCSI I/O Controller Protocol + rmt8 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt9 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt10 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt11 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs2 61-08 FC Adapter * fscsi261-08-01 FC SCSI I/O Controller Protocol + rmt12 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt13 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt14 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt15 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs3 71-08 FC Adapter * fscsi371-08-01 FC SCSI I/O Controller Protocol + rmt16 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt17 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt18 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt19 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs0 21-08 FC Adapter * fscsi021-08-01 FC SCSI I/O Controller Protocol + rmt4 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt5 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt6 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt7 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) In the example above using one drive for my explaination rmt8, rmt12, rmt16 and rmt4 are the same physical drive seen across four FC paths. so in this case I would pick rmt8. Second drive can be seen as rmt9, rmt13, rmt17 and rmt5 so I use rmt13 and so on. If you run like this then you are maxing the throughput available to each drive Please note the IBM recommendation is no more than 2 drives per FC adapter. With the above configuration we achieve tape-to-tape of around 40-80GB an hour (depending on data and client/server compression). A couple of other tweaks we have set in dsmserv.opt TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 5000 Finally on the devclass we have set the format to ultriumc. Let me know how you get on Cheers Andy Wilcox Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.63 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England and Wales number 3600545 This e-mail may be sent on behalf of any of the Companies.
Re: Slow tape to tape performance
FYI. Quoted from the Admin Ref: MOVESizethresh megabytes Parameters megabytes Specifies the number of megabytes as an integer from 1 to 2048. Zlatko Krastev IT Consultant Wilcox, Andy [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 27.12.2002 13:46 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Slow tape to tape performance Firstly I must ask people to accept my apologisies if this message doesn't look right This is first time I have tried to post a message hear :-) Just reading through a scenario posted by Michael Wheelock about slow tape to tape perforance... There are lots of considerations here to take note of... We run with an P660-6M1 (near enough a similar server) with a 3584 attached to four HVD SCSI LTO Drives and four FC LTO Drives (over a SAN). Each SCSI drive is attached directly to its own SCSI card in the server to max the performance. With the FC drives we can see all four over each of the four FC adapters in the server. You need to make sure you use the as few drives on one FC bus as possible... + fcs1 51-08 FC Adapter * fscsi151-08-01 FC SCSI I/O Controller Protocol + rmt8 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt9 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt10 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt11 51-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs2 61-08 FC Adapter * fscsi261-08-01 FC SCSI I/O Controller Protocol + rmt12 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt13 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt14 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt15 61-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs3 71-08 FC Adapter * fscsi371-08-01 FC SCSI I/O Controller Protocol + rmt16 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt17 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt18 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt19 71-08-01 IBM 3580 Ultrium Tape Drive (FCP) + fcs0 21-08 FC Adapter * fscsi021-08-01 FC SCSI I/O Controller Protocol + rmt4 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt5 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt6 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) + rmt7 21-08-01 IBM 3580 Ultrium Tape Drive (FCP) In the example above using one drive for my explaination rmt8, rmt12, rmt16 and rmt4 are the same physical drive seen across four FC paths. so in this case I would pick rmt8. Second drive can be seen as rmt9, rmt13, rmt17 and rmt5 so I use rmt13 and so on. If you run like this then you are maxing the throughput available to each drive Please note the IBM recommendation is no more than 2 drives per FC adapter. With the above configuration we achieve tape-to-tape of around 40-80GB an hour (depending on data and client/server compression). A couple of other tweaks we have set in dsmserv.opt TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 5000 Finally on the devclass we have set the format to ultriumc. Let me know how you get on Cheers Andy Wilcox Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.63 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the Companies) accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England
Slow tape to tape performance...
Hi, I am getting agonizingly slow (~1GB/hr) performance on tape to tape copies (such as during reclamations). Is this normal? This is a new install, fairly fresh with some basic policies and copy groups. The server is an AIX 5.1 ML02 7026-M80 with 8GB RAM. The tape library is an IBM 3584 with 8 FC attached LTO drives. TSM is at 5.1.5.4. Any ideas would be appreciated. Michael Wheelock Integris Health of Oklahoma
Re: Slow tape to tape performance...
do you have tape drive compression and client compression turned on? I've seen this before with AIT drives trying to compress already compressed data... -Original Message- From: Wheelock, Michael D [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 11:33 AM To: [EMAIL PROTECTED] Subject: Slow tape to tape performance... Hi, I am getting agonizingly slow (~1GB/hr) performance on tape to tape copies (such as during reclamations). Is this normal? This is a new install, fairly fresh with some basic policies and copy groups. The server is an AIX 5.1 ML02 7026-M80 with 8GB RAM. The tape library is an IBM 3584 with 8 FC attached LTO drives. TSM is at 5.1.5.4. Any ideas would be appreciated. Michael Wheelock Integris Health of Oklahoma Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Slow tape to tape performance...
Performance is good when writing from disk to tape? How good? When I hear of this I suspect driver issues. I know on Win2K driver selection is paramount when having a performance problem with tape. Kelly J. Lipp STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Remeta, Mark Sent: Tuesday, December 24, 2002 10:08 AM To: [EMAIL PROTECTED] Subject: Re: Slow tape to tape performance... do you have tape drive compression and client compression turned on? I've seen this before with AIT drives trying to compress already compressed data... -Original Message- From: Wheelock, Michael D [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 24, 2002 11:33 AM To: [EMAIL PROTECTED] Subject: Slow tape to tape performance... Hi, I am getting agonizingly slow (~1GB/hr) performance on tape to tape copies (such as during reclamations). Is this normal? This is a new install, fairly fresh with some basic policies and copy groups. The server is an AIX 5.1 ML02 7026-M80 with 8GB RAM. The tape library is an IBM 3584 with 8 FC attached LTO drives. TSM is at 5.1.5.4. Any ideas would be appreciated. Michael Wheelock Integris Health of Oklahoma Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Slow tape to tape performance...
I am getting agonizingly slow (~1GB/hr) performance on tape to tape copies (such as during reclamations). What experiments have you performed to try to narrow down the problem? What results do you see in an experiment where data is copied between the same two tape drives outside of TSM? Given the cost of FC adapters, is it the case that you have one, and you are seeing tidal action as drive-to-drive copies are performed? As Kelly suggested, the driver level for the FC adapter may greatly affect performance. I presume that you are seeing this performance problem with all tapes? Marginal tape samples can result in a lot of retries, and degraded performance. Don't overlook microcode level on the drives: some mc levels are bow-wows. Richard Sims, BU
Re: tape-to-tape performance
What sort of performance are you getting? In Gbyte/hour. I would expect somewhere in the 40-60 GB/hour range. Kelly J. Lipp STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Bassi Sent: Wednesday, November 20, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance Take a look at the movebatchsize, movesizethresh and bufpoolsize. These 3 options have a direct corrolation for tape to tape copy processes. -- Joshua S. Bassi IBM Certified - AIX 4/5L, SAN, Shark Tivoli Certified Consultant - ADSM/TSM eServer Systems Expert -pSeries HACMP AIX, HACMP, Storage, TSM Consultant Cell (831) 595-3962 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Conko, Steven Sent: Wednesday, November 20, 2002 11:26 AM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: tape-to-tape performance
As much of a performance hit as you want ! With about every TSM task (straight backups via resourceutilization or with tdp/r3 with the number of concurrent sessions, etc...) you can tune how busy TSM will keep your system. We have our production boxes at one site and our disaster recovery center miles away, our TSM server(s) are located at the DR site, we have to compress all client data to send it across the OC12 between the sites. For example, we can crank up TSM activities to suck up 90% of 20 processors (out of 32) on a Sun E10K by using client compression... So an OC12 is 622 Mb/sec or roughly 273 GB/hr, on a nightly basis we see it running somewhere between 175-200 GB/hr so we still have about 1/3 capacity BUT we see 3.8/1 compression of most data base data so we are actually moving somewhere around 760 GB/hr of client filespace and I'd hate to be pay'n for an OC24 (or more) between the sites (if we could even get it) ! One view is that if you beef up the processors to assist in backup, the end results to the user community is increased performance during their production use ;-) It's a (god I hat to say this) WIN ! WIN ! situation... Just remind management that today they are more than ever likely to have to depend on their DR ! Dwight -Original Message- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:35 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance thanks for that insight. i forgot to mention we are running fibre channel and not scsi drives. yes, the data is must have... it is all production data and is being copied for DRM. how much of a performance hit will it take to turn compression on at the client level? -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:22 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance Is 1.6 TB the amount of must have/critical information ? and is that already compressed ? Knowing each tape mount runs about 90 seconds, any way to reduce tape mounts will speed up copies. If you have collocation on, turning it off ~could~ help... and collocation can/is set on both primary pools and copy pools. Now if the data isn't compressed by the client the data is uncompressed at the drive, moved through the processor as ~full size~ data, then recompressed at the destination drive. If your clients have the horsepower, turn on client compression, that way not so much data is moved across the processor's buss. Don't daisy chain any of your 3590's if they are older scsi. You might be able to reduce your data down if you force the application owners to review their required CRITICAL/MUST HAVE data and send it to isolated pools for copies to take offsite. just some thoughts... Dwight -Original Message- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
tape-to-tape performance
we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: tape-to-tape performance
The storage pool backup that you are doing could be directly affected by the database performance. Is this 1.6TB a lot of small files? On the IO configuration side, how are your tape drives connected, SCSI or FC? I suspect SCSI. If you have more than 2 drives, on a SCSI adapter that is the problem. If they are E-model they really should be 2 per adapter to get descent performance. On a FC scenario you can go up to 4 drives per FC adapter and have very good performance. I have gone has high as 8 per FC adapter, but performance does suffer then. If you are using FC, make sure your FC tape and disk are not on the same adapters on a TSM server. Other applications it is fine, but not this one. If your TSM database is on slow disk that will slow down the copies. It has to create a lot of updates to the database to copy the storage pools. Paul D. Seay, Jr. Technical Specialist Naptheon Inc. 757-688-8180 -Original Message- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:26 PM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: tape-to-tape performance
Take a look at the movebatchsize, movesizethresh and bufpoolsize. These 3 options have a direct corrolation for tape to tape copy processes. -- Joshua S. Bassi IBM Certified - AIX 4/5L, SAN, Shark Tivoli Certified Consultant - ADSM/TSM eServer Systems Expert -pSeries HACMP AIX, HACMP, Storage, TSM Consultant Cell (831) 595-3962 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Conko, Steven Sent: Wednesday, November 20, 2002 11:26 AM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: tape-to-tape performance
Is 1.6 TB the amount of must have/critical information ? and is that already compressed ? Knowing each tape mount runs about 90 seconds, any way to reduce tape mounts will speed up copies. If you have collocation on, turning it off ~could~ help... and collocation can/is set on both primary pools and copy pools. Now if the data isn't compressed by the client the data is uncompressed at the drive, moved through the processor as ~full size~ data, then recompressed at the destination drive. If your clients have the horsepower, turn on client compression, that way not so much data is moved across the processor's buss. Don't daisy chain any of your 3590's if they are older scsi. You might be able to reduce your data down if you force the application owners to review their required CRITICAL/MUST HAVE data and send it to isolated pools for copies to take offsite. just some thoughts... Dwight -Original Message- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: tape-to-tape performance
thanks for that insight. i forgot to mention we are running fibre channel and not scsi drives. yes, the data is must have... it is all production data and is being copied for DRM. how much of a performance hit will it take to turn compression on at the client level? -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 3:22 PM To: [EMAIL PROTECTED] Subject: Re: tape-to-tape performance Is 1.6 TB the amount of must have/critical information ? and is that already compressed ? Knowing each tape mount runs about 90 seconds, any way to reduce tape mounts will speed up copies. If you have collocation on, turning it off ~could~ help... and collocation can/is set on both primary pools and copy pools. Now if the data isn't compressed by the client the data is uncompressed at the drive, moved through the processor as ~full size~ data, then recompressed at the destination drive. If your clients have the horsepower, turn on client compression, that way not so much data is moved across the processor's buss. Don't daisy chain any of your 3590's if they are older scsi. You might be able to reduce your data down if you force the application owners to review their required CRITICAL/MUST HAVE data and send it to isolated pools for copies to take offsite. just some thoughts... Dwight -Original Message- From: Conko, Steven [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:26 PM To: [EMAIL PROTECTED] Subject: tape-to-tape performance we run a 3494 tape library with 3590 tape drives. after our backup are finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as you can imagine, even with 8 drives this takes some time. are there any server, device or other parameters we can tune to improve the tape-to-tape performance? steve
Re: Tape Performance on 3580
While your co-worker is correct that the Fibre Channel payload is approximately 2k, the logical leap that you would want to match your blocksize to the Fibre channel payload size is completely erroneous. Having a blocksize of 2k as opposed to 256k induces a 128 fold increase in the communication overhead. I.E. for every 256KB of data you are going through the protocol overhead 128 more times. It's like buying groceries, but instead of filling up your cart and taking it to the checkout cashier, you get 1 item at a time and bring it to the cashier. But you not only bring 1 item at a time, but you pay for each item individually. The checkout cashier's bar code reader can only handle one item at a time, so you might as well get one item at a time. The tape drive and the fibre channel protocol both perform significantly better at 256KB blocksizes. James Thompson _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Tape Performance on 3580
Hi guys, this is actually not a TSM question but one for the hardware gurus. We are running a backup under AIX using the savevg command and Ultrium 3580 tape drives. With topas I can see a data transfer rate of about 1MB/sec. We attached the drives via Fibre Channel and a SAN Data Gateway. The blocksize of the drive was set to 2048 (since one of the SAN guys told me FC transfers with a blocksize of 2048). I started savevg with -b4 meaning to write 4x512Byte blocks (=2048). With the mentioned speed the drives are seriously crawling. Am I missing out something here? Any clues?? Thanks Lars
Re: Tape Performance on 3580
Lars Bebensee wrote: Hi guys, this is actually not a TSM question but one for the hardware gurus. We are running a backup under AIX using the savevg command and Ultrium 3580 tape drives. With topas I can see a data transfer rate of about 1MB/sec. We attached the drives via Fibre Channel and a SAN Data Gateway. The blocksize of the drive was set to 2048 (since one of the SAN guys told me FC transfers with a blocksize of 2048). I started savevg with -b4 meaning to write 4x512Byte blocks (=2048). With the mentioned speed the drives are seriously crawling. Am I missing out something here? Any clues?? Thanks Lars Hi, I think your problem is you are not feeding the data to the tape drive fast enough for it to stream, therefore it is stopping waiting for data and then starts when it gets some. The stop and starts kill the performance. I would try increasing two different values: chdev -l sys0 -a maxbuf=100 savevg -b200 . This should improve the streaming of data to the tape drive. You may have to play with these numbers some to get the optimal performance. Good Luck and let us know how you did. -- Regards, Mark D. Rodriguez President MDR Consulting, Inc. === MDR Consulting The very best in Technical Training and Consulting. IBM Advanced Business Partner SAIR Linux and GNU Authorized Center for Education IBM Certified Advanced Technical Expert, CATE AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux Red Hat Certified Engineer, RHCE ===
Re: Tape Performance on 3580
Just a guess -- but I'd ignore the FC transfer size and use a device blocksize of 128K or 256K (can't remember off the top of my head what LTO uses as a maximum). The FC transport layer should split/reassemble the blocks with no problem. For example, our SAP database is FC attached and Oracle is configured to use an 8K blocksize for all disk I/O -- and that's been working for several years now. Tom Kauffman NIBCO, Inc -Original Message- From: Lars Bebensee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 9:24 AM To: [EMAIL PROTECTED] Subject: Tape Performance on 3580 Hi guys, this is actually not a TSM question but one for the hardware gurus. We are running a backup under AIX using the savevg command and Ultrium 3580 tape drives. With topas I can see a data transfer rate of about 1MB/sec. We attached the drives via Fibre Channel and a SAN Data Gateway. The blocksize of the drive was set to 2048 (since one of the SAN guys told me FC transfers with a blocksize of 2048). I started savevg with -b4 meaning to write 4x512Byte blocks (=2048). With the mentioned speed the drives are seriously crawling. Am I missing out something here? Any clues?? Thanks Lars
Re: Tape Performance on 3580
LTO drives will crawl unless they are streamed. The LTO blocksize should be set as high as possible, 256KB is not to large. If your disk and application cannot write at 15 MB/sec, the best you can expect is a few MB/sec. There is no in-between. Orville L. Lantto Datatrend Technologies, Inc. (http://www.datatrend.com) IBM Premier Business Partner 121 Cheshire Lane, Suite 700 Minnetonka, MN 55305 Email: [EMAIL PROTECTED] Lars Bebensee [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 08/13/02 09:24 AM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Tape Performance on 3580 Hi guys, this is actually not a TSM question but one for the hardware gurus. We are running a backup under AIX using the savevg command and Ultrium 3580 tape drives. With topas I can see a data transfer rate of about 1MB/sec. We attached the drives via Fibre Channel and a SAN Data Gateway. The blocksize of the drive was set to 2048 (since one of the SAN guys told me FC transfers with a blocksize of 2048). I started savevg with -b4 meaning to write 4x512Byte blocks (=2048). With the mentioned speed the drives are seriously crawling. Am I missing out something here? Any clues?? Thanks Lars
Re: BACKUP to TAPE, PERFORMANCE
This is likely not a tape issue. 52GB/hr is about 14.8MB/sec. I am betting your disk cannot read the data any faster than that. Unless the data is not compressable at all the typical rates for a SCSI Magstar drive are 25+MB/sec and can get as high as 34 on Ultra SCSI if the cables are real short. Fibre Channel easily gets 33. What kind of disk is the source? Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Gianluca Perilli [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 30, 2002 1:02 PM To: [EMAIL PROTECTED] Subject: Re: BACKUP to TAPE, PERFORMANCE HI Francisco, as far as I know the maximun native throughput of a 3590 drive is 12 MB/s. If you want something to refer to as a rule of thumb,these are the performance of the 3590 library: (Embedded image moved to file: pic19254.pcx) so you can check if you are having good performance in your environment. For more information about 3590 tape performances you can refer to this whitepaper: http://www.storage.ibm.com/hardsoft/tape/3590/prod_data/3590wp6.pdf Cordiali saluti / Best regards Gianluca Perilli Gianluca Perilli Tivoli Customer Support Via Sciangai n° 53 - 00144 Roma (Italy) Tel. 06/5966 - 4581 Cell. 335/7840985 Francisco Molero [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: ADSM: Subject: BACKUP to TAPE, PERFORMANCE Dist Stor Manager [EMAIL PROTECTED] .EDU 05/29/2002 12:00 PM Please respond to ADSM: Dist Stor Manager Hi everybody, My question is simple. We are running selective backup through Gigabit, and my STGpool is 3590 Tape Pool. I want to know, how many Gigabytes you backup per hour?? For bigger files I get a 52 GByte/hour. And I think these is very slow. This test is only 1 client and no other clients are accessing to Server. Any Ideas Thanks, Fran. ___ Copa del Mundo de la FIFA 2002 Disfruta en vmdeo de los mejores momentos desde tu ordenador. http://fifaworldcup.yahoo.com/fc/es/
Re: BACKUP to TAPE, PERFORMANCE
I thought it was 16MB/sec B1A model type, and up to 24MB for E1A Gabriel C. Wiley ADSM/TSM Administrator AIX Support Phone 1-614-308-6709 Pager 1-877-489-2867 Fax 1-614-308-6637 Cell 1-740-972-6441 Siempre Hay Esperanza |-+ | | Gianluca | | | Perilli/Italy/IBM| | | @IBMIT | | | Sent by: ADSM: | | | Dist Stor| | | Manager | | | [EMAIL PROTECTED]| | | .EDU| | || | || | | 05/30/2002 01:02 | | | PM | | | Please respond to| | | ADSM: Dist Stor | | | Manager | | || |-+ --| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: BACKUP to TAPE, PERFORMANCE | | | | | --| HI Francisco, as far as I know the maximun native throughput of a 3590 drive is 12 MB/s. If you want something to refer to as a rule of thumb,these are the performance of the 3590 library: (Embedded image moved to file: pic19254.pcx) so you can check if you are having good performance in your environment. For more information about 3590 tape performances you can refer to this whitepaper: http://www.storage.ibm.com/hardsoft/tape/3590/prod_data/3590wp6.pdf Cordiali saluti / Best regards Gianluca Perilli Gianluca Perilli Tivoli Customer Support Via Sciangai n° 53 - 00144 Roma (Italy) Tel. 06/5966 - 4581 Cell. 335/7840985 Francisco Molero [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: ADSM: Subject: BACKUP to TAPE, PERFORMANCE Dist Stor Manager [EMAIL PROTECTED] .EDU 05/29/2002 12:00 PM Please respond to ADSM: Dist Stor Manager Hi everybody, My question is simple. We are running selective backup through Gigabit, and my STGpool is 3590 Tape Pool. I want to know, how many Gigabytes you backup per hour?? For bigger files I get a 52 GByte/hour. And I think these is very slow. This test is only 1 client and no other clients are accessing to Server. Any Ideas Thanks, Fran. ___ Copa del Mundo de la FIFA 2002 Disfruta en vmdeo de los mejores momentos desde tu ordenador. http://fifaworldcup.yahoo.com/fc/es/ pic19254.pcx has been removed from this note on May 29 2002 by Gabriel Wiley
BACKUP to TAPE, PERFORMANCE II
Hi again, I only use one drive. This is important. Sorry for my previous mail. Client Options: nodename IBM_TEST ERRORLOGRETENTION 5 PASSWORDACCESS GENERATE SCHEDLOGRETENTION 5 SCHEDMODE PROMPTED TCPB32 TCPNYES TCPPORT 1500 TCPSERVERADDRESSTSMSERVER TCPW64 TXNB1048576 largecommbufno Server Options : SELFTUNEBUFpoolsize yes SELFTUNETXNsize yes COMMmethod TCPIP COMMmethod SHAREDMEM COMMmethod HTTP TCPPort 1500 HTTPPort 1580 LOGPoolsize 2048 LANGuage en_US DATEformat 1 TIMEformat 1 MIRRORWRITE DB SEQUENTIAL MSGINTerval 1 MAXSESSIONS 5000 ENABLE3590LIBRARY YES COMMTIMEOUT 600 IDLETIMEOUT 600 bufpoolsize 262144 tcpwindowsize 64 TXNGroupmax 256 TCPBufsize 32 MOVEBatchsize 1000 MoveSizethresh500 USELARGEBUFFERS Yes LOGPoolsize 2048 HW: FC DISKS ( COMPAQ ARRAY) - TSM CLIENT TRU64 (4 PROC and 4GB RAM) - GIGABIT ETH - TSM SERVER 1GB RAM AND 1 PROCESSOR - 3494 with on drive 3590E FC. ___ Copa del Mundo de la FIFA 2002 El znico lugar de Internet con vmdeos de los 64 partidos. !Apzntante ya! en http://fifaworldcup.yahoo.com/fc/es/
Re: BACKUP to TAPE, PERFORMANCE
Francisco, those numbers are normal. 3590 drives have a native transfer rate of 12MB/s. that makes around the 50GB/h mark. to have more than that you have to compress your data, and the 3590 can compress up to 3:1. whether you can do that or not depends on your data (3:1 compression ratios are generally achieved only in mainframe world; in open systems you would expect something closer to 2:1). other than that, it depends on the number of tape drives used, and the bandwidth occupancy at backup time if you are in a LAN environment as it would seem to be your case. Cordiali saluti Gianluca Mariani Tech Support SSD Via Sciangai 53, Roma phones : +39(0)659664598 +393351270554 (mobile) [EMAIL PROTECTED] Francisco Molero [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: ADSM: Subject: BACKUP to TAPE, PERFORMANCE Dist Stor Manager [EMAIL PROTECTED] .EDU 05/29/2002 12:00 PM Please respond to ADSM: Dist Stor Manager Hi everybody, My question is simple. We are running selective backup through Gigabit, and my STGpool is 3590 Tape Pool. I want to know, how many Gigabytes you backup per hour?? For bigger files I get a 52 GByte/hour. And I think these is very slow. This test is only 1 client and no other clients are accessing to Server. Any Ideas Thanks, Fran. ___ Copa del Mundo de la FIFA 2002 Disfruta en vmdeo de los mejores momentos desde tu ordenador. http://fifaworldcup.yahoo.com/fc/es/
Re: BACKUP to TAPE, PERFORMANCE II
Fran, one parameter you can change is Bufpoolsize on the server. for 1GB of real RAM you should put it to 131072. the other thing is to turn compression off, in a single client, fast client, fast server, fast network it gives better performance. then on the AIX server try no -o rfc1323=1 no -o thewall=131072 no -o sb_max=1310720 use vmtune to view virtual memory settings. if the filesystem is jfs you should put maxpgahead to maximum (-R256). stop virtual memory paging by modifying minperm/maxperm parameters (default is -P80, lower it to -P50 but watch minperm). on the client check if compression actually makes files bigger, and check how many retries there are when sending data to server. put TxnGroupMax to the maximum (256) if retries are rare. you can raise TxnByteLimit (maximum is 2097152). MoveBatchSize should be 1000, MoveSizeThresh 500 (2048 for TSM 5.1), set ExpInterval to 0. then pray... Cordiali saluti Gianluca Mariani Tech Support SSD Via Sciangai 53, Roma phones : +39(0)659664598 +393351270554 (mobile) [EMAIL PROTECTED] Francisco Molero [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: ADSM: Subject: BACKUP to TAPE, PERFORMANCE II Dist Stor Manager [EMAIL PROTECTED] .EDU 05/30/2002 12:33 PM Please respond to ADSM: Dist Stor Manager Hi again, I only use one drive. This is important. Sorry for my previous mail. Client Options: nodename IBM_TEST ERRORLOGRETENTION 5 PASSWORDACCESS GENERATE SCHEDLOGRETENTION 5 SCHEDMODE PROMPTED TCPB32 TCPNYES TCPPORT 1500 TCPSERVERADDRESSTSMSERVER TCPW64 TXNB1048576 largecommbufno Server Options : SELFTUNEBUFpoolsize yes SELFTUNETXNsize yes COMMmethod TCPIP COMMmethod SHAREDMEM COMMmethod HTTP TCPPort 1500 HTTPPort 1580 LOGPoolsize 2048 LANGuage en_US DATEformat 1 TIMEformat 1 MIRRORWRITE DB SEQUENTIAL MSGINTerval 1 MAXSESSIONS 5000 ENABLE3590LIBRARY YES COMMTIMEOUT 600 IDLETIMEOUT 600 bufpoolsize 262144 tcpwindowsize 64 TXNGroupmax 256 TCPBufsize 32 MOVEBatchsize 1000 MoveSizethresh500 USELARGEBUFFERS Yes LOGPoolsize 2048 HW: FC DISKS ( COMPAQ ARRAY) - TSM CLIENT TRU64 (4 PROC and 4GB RAM) - GIGABIT ETH - TSM SERVER 1GB RAM AND 1 PROCESSOR - 3494 with on drive 3590E FC. ___ Copa del Mundo de la FIFA 2002 El znico lugar de Internet con vmdeos de los 64 partidos. !Apzntante ya! en http://fifaworldcup.yahoo.com/fc/es/
BACKUP to TAPE, PERFORMANCE
Hi everybody, My question is simple. We are running selective backup through Gigabit, and my STGpool is 3590 Tape Pool. I want to know, how many Gigabytes you backup per hour?? For bigger files I get a 52 GByte/hour. And I think these is very slow. This test is only 1 client and no other clients are accessing to Server. Any Ideas Thanks, Fran. ___ Copa del Mundo de la FIFA 2002 Disfruta en vmdeo de los mejores momentos desde tu ordenador. http://fifaworldcup.yahoo.com/fc/es/
Re: BACKUP to TAPE, PERFORMANCE
HI Francisco, as far as I know the maximun native throughput of a 3590 drive is 12 MB/s. If you want something to refer to as a rule of thumb,these are the performance of the 3590 library: (Embedded image moved to file: pic19254.pcx) so you can check if you are having good performance in your environment. For more information about 3590 tape performances you can refer to this whitepaper: http://www.storage.ibm.com/hardsoft/tape/3590/prod_data/3590wp6.pdf Cordiali saluti / Best regards Gianluca Perilli Gianluca Perilli Tivoli Customer Support Via Sciangai n° 53 - 00144 Roma (Italy) Tel. 06/5966 - 4581 Cell. 335/7840985 Francisco Molero [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: ADSM: Subject: BACKUP to TAPE, PERFORMANCE Dist Stor Manager [EMAIL PROTECTED] .EDU 05/29/2002 12:00 PM Please respond to ADSM: Dist Stor Manager Hi everybody, My question is simple. We are running selective backup through Gigabit, and my STGpool is 3590 Tape Pool. I want to know, how many Gigabytes you backup per hour?? For bigger files I get a 52 GByte/hour. And I think these is very slow. This test is only 1 client and no other clients are accessing to Server. Any Ideas Thanks, Fran. ___ Copa del Mundo de la FIFA 2002 Disfruta en vmdeo de los mejores momentos desde tu ordenador. http://fifaworldcup.yahoo.com/fc/es/ pic19254.pcx Description: Binary data
Tape Performance
I have a bunch of questions regarding tape drive performance and backup software. We are planning to evaluate Tivoli Storage Manager and Veritas Netbackup. The decision as to which one is going to be purchased is out of my hands. I am however responsible for determining what tape hardware to purchase. I am somewhat familiar with Tivoli Storage Manager, but do not have any experience with Veritas. My first question is how does TSM and Veritas compare regarding tape usage. With TSM and its file level based granularity, it seems like the tape locate speeds would be one of the most important considerations. The way I see it if you only have fast streaming performance, then sure your migrations and backups will be fast, but reclamation and file system recovery with the active versions of data spread across a tape will have poor performance. Is this accurate? Does Veritas ever run into similar situations during entire file system recovery? Does Veritas have anything like reclamation? Are there any reports that compare the various tape drives in 'real world' situations? When you buy/evaulate new tape hardware for use with Tivoli Storage Manager, how do you determine the performance in a sandbox environment that would allow you to determine how well it will do once it is put into production? I have the same question as above regarding a Veritas Netbackup environment. And finally if there are no reports of 'real world' situations comparing the various tape drives, what types of sitations would you like to see (In case anyone is monitoring the listserv who can do something about this lack of information). Clayton Thompson -- ___ Have you downloaded the latest calling software from Net2Phone? Click here to get it now! http://www.net2phone.com/cgi-bin/adforward.cgi?p_key=NH211JKurl=http://commcenter.net2phone.com/
Tape performance tuning help
I have been asked to perform some performance tuning on some WinNT, Win2k, Sun, AIX systems. We just received a 3583 with 2 3580 drives, and I need to show some performance numbers across those platforms. This is currently a sandbox environment. I am interested in any tips/techniques for tuning the OS or Tape drive options for enhancing performance. I am also interested in any tools that can be used to monitor the system to isolate bottlenecks. Lastly if there is any good written material that you could point me to I would appreciate it. I want to first get some base results using OS commands, then compare that to the results that TSM gets. James Thompson _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Tape performance tuning help
U have to do both on OS and TSM . For OS u have to go to IBM WEB SITE and u will see tons of info on that. As per TSM it also has parameters ex: window size etc. in implementation of Tivoli REDBOOKS ON IBM SITE. For tape drives u got to look at their respective sites. PL use compressed mode on clients for better n/w xfer rate and keep tcp/ip speed at 100mbs /sec .Configure I/f accordingly. Keep patches on OS sever and clients up to date to avoid memory leaks. Its a very long info u need to do lot of home work and go to respective web sites.\ It took me one month to do the same on HP/AIX/SUN/NT/TSM. BALANAND PINNI. PHONE 314-206-5911. EM:[EMAIL PROTECTED] PG:1-800-451-6897. -Original Message- From: James Thompson [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 9:30 AM To: [EMAIL PROTECTED] Subject: Tape performance tuning help I have been asked to perform some performance tuning on some WinNT, Win2k, Sun, AIX systems. We just received a 3583 with 2 3580 drives, and I need to show some performance numbers across those platforms. This is currently a sandbox environment. I am interested in any tips/techniques for tuning the OS or Tape drive options for enhancing performance. I am also interested in any tools that can be used to monitor the system to isolate bottlenecks. Lastly if there is any good written material that you could point me to I would appreciate it. I want to first get some base results using OS commands, then compare that to the results that TSM gets. James Thompson _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Tape performance tuning help
There is a performance tuning guide off of Tivoli's web site for ADSM/TSM. --- James Thompson [EMAIL PROTECTED] wrote: I have been asked to perform some performance tuning on some WinNT, Win2k, Sun, AIX systems. We just received a 3583 with 2 3580 drives, and I need to show some performance numbers across those platforms. This is currently a sandbox environment. I am interested in any tips/techniques for tuning the OS or Tape drive options for enhancing performance. I am also interested in any tools that can be used to monitor the system to isolate bottlenecks. Lastly if there is any good written material that you could point me to I would appreciate it. I want to first get some base results using OS commands, then compare that to the results that TSM gets. James Thompson _ Get your FREE download of MSN Explorer at http://explorer.msn.com __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
