Re: LTO throughput - real world experiences
Michael, Regarding automation of collecting throughput performance stats directly from SAN switches, I would suggest, although I haven't tried it, that automation is possible through the SNMP agent on most switches. IBM 2109's, for example, I recall have a fairly comprehensive set of data available reporting throughput per port, and an SNMP get script could pull these stats at a given interval to a machine elsewhere on the network. IBM/Tivoli Netview I seem to remember has performance monitoring via MIB's in-built and can automate this fairly easily, even displaying the data in a chart if necessary. That being said, I'm sure there are dozens of other SAN management tools out there which perform similar performance/stat/event gathering functions - it's just a question of how complex they are, and how much you'd want to pay for them! Rgds, David McClelland Global Management Systems Reuters, London -Original Message- From: Wheelock, Michael D [mailto:[EMAIL PROTECTED] Sent: 08 July 2003 18:41 To: [EMAIL PROTECTED] Subject: [spam] Re: LTO throughput - real world experiences Hi, If you have fibre connected LTO drives, one really simple way is to connect to the web console of the switch and monitor the performance of the ports on the switch. This isn't easily automatable, but it is a very accurate representation of what you are seeing in terms of throughput. Michael Wheelock Integris Health of Oklahoma -Original Message- From: Shawn Price [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:36 PM To: [EMAIL PROTECTED] Subject: Re: LTO throughput - real world experiences What is the best way to determine what your throughput is for each process? Are you just going by the activity log? Thanks! Shawn >>> [EMAIL PROTECTED] 07/08/03 1:34 PM >>> >I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. It varies drastically for us based upon the objects being moved, of course. 10-15MB/s / drive is normal for us overall. >How many MB/sec does a migration process produce in your environment? We achieve about 12-14MB/s per drive when performing migration. >Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Yes, our Exchange boxes stream nicely at about 15MB/s per drive. HTH! Chris Murphy IT Network Analyst Idaho Dept. of Lands Office: (208) 334-0293 [EMAIL PROTECTED] This e-mail may contain identifiable health information that is subject to protection under state and federal law. This information is intended to be for the use of the individual named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited and may be punishable by law. If you have received this electronic transmission in error, please notify us immediately by electronic mail (reply). -- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
Re: LTO throughput - real world experiences
>What is the best way to determine what your throughput is for each process? Are you just going by the activity log? I have measured it a couple of ways. As many have said, from the switch ports is an excellent (though manual) process. Be warned there is a slight FC overhead on every frame, and as I recall, the numbers on most switches is the gross throughput (includes overhead), not net. I have also used the TDP data for Exchange, which logs the throughput speed from TSMs' perspective. This is where we achieve around 15MB/s which I think is about all our little Exchange box can push to be honest. Thirdly, depending on your disk arrays, some have utils that will give info as well. We use a FAStT box and which has LUN's specifically assigned to storage pools. I can get some idea of its ability through the management util (IBM FAStT Storage Manager) for it, but also have to weary of other activity on that array, of course. Chris
Re: LTO throughput - real world experiences
Gerald, I am glad you asked this question as I was thinking of posting a similar question myself. Here is our configuration: IBM F50 4-way AIX 4.3.3 ML 11 1 GB RAM Overland Neo 4000 library with 4 Seagate LTO-1 drives, hardware compression on 2 6205 Ultra2 SCSI Interface cards (2 drives per/port with library on its own port) TSM 5.1.5.4 Before I started to play with some server side parameters (MoveBatchSize, MoveSizeThresh, BuffPoolSize), I was getting about 4-5 MB/s tape throughput on a primary pool copy operation. After cranking up the three parameters from their defaults (MoveBatchSize (# objects) 40->1000, MoveSizeThresh (MB) 500->2048, BuffPoolSize (KB) 2048->131072) I am now getting 11-12 MB/s tape throughput on that same primary pool copy operation. My two cents. Marc Taylor
Re: LTO throughput - real world experiences
Another comment... LTO numbers should probably be reported as being LTO-1 or LTO-2. LTO-1 max uncompressed is 15 MB/sec, max compressed is 30 MB/sec; LTO-2 max uncompressed is 35 MB/sec, max compressed is 70 MB/sec. This assumes a typical average compression ratio of 2:1, of course. We use tapeutil under AIX (part of the Atape driver) to test the raw throughput to tape with the rwtest option. May be possible to do similar tests with other tools under other OSes. We did this with the drive in question disabled in TSM then put an unused blank tape (unlabelled and unknown to TSM) in the upper I/O station, closed the door, then did: # tapeutil -f /dev/smc0 move 769 257 (move from first I/O station slot to first drive in first frame; AIX knows this drive as rmt0 in our case. **MAKE SURE YOU VERIFY THE ELEMENT ID FOR DRIVE TO OS'S DRIVE NAME MAPPING OR YOU COULD DESTROY A TAPE WITH VALID DATA ON IT!!!**) # tapeutil -f /dev/rmt0 rwtest -b 262144 -c 20 -r 3 (do a destructive read/write test with a 256K block size factor, run for 20 blocks for each read test, 20 blocks for each write test, and do both set of tests 3 times) # tapeutil -f /dev/smc0 move 257 769 (put the tape back in the upper I/O station slot when done) This destroys the ANSI tape label so it's best to do this on a previously unused tape or you'll have to re-label (dsmlabel or 'LABEL VOLUME') it afterwards. And then, of course, re-enable the drive within TSM. That gives us some idea of the raw potential. Then within TSM, I like to see how fast it can push large files through to tape in a diskpool->tape pool migration. Of course, this is also another 'test best case' scenario because tape drives are more optimized for large files than for a number of small ones, but it still gives you an idea about the upper bound of real world performance. Between the tests and TSM tape writes, it appears we get 22.5 MB/sec sustained in compressed mode for LTO-1 drives. That's pretty decent; it's halfway between the theoretical min and max for compressed mode, and we're happy by its performance so we've got no complaints :-) I should note that we don't really do database backups (well, we usually export them to a SQL dump file in ASCII and back that up because the TDP type tools are priced *outrageously* and our needs aren't _that_ pressing) and that our data generally compresses well to tape -- we get an average of 2.24:1 hardware compression across the entire tape pool with a few bursts of 3:1 and once, almost 4:1 compression for a LTO-1 tape. The only way we get this kind of performance is to put a disk pool in front of the tape drives... and we also limit it to two drives per SCSI bus (because they're capable of peaking at 30 MB/sec or so in compressed mode... so 2x30 = 60 MB/sec which means you need at least a Ultra2 SCSI controller) to avoid contention or bottlenecks at the bus level. The earlier tips about testing the FC setup was good, too. -Dan
Re: LTO throughput - real world experiences
>What is the best way to determine what your throughput is for each >process? Are you just going by the activity log? One of the many things Servergraph/TSM (http://www.servergraph.com) will report for you is thoughput rates for the various TSM processes. David Ehresman University of Louisville
Re: LTO throughput - real world experiences
Hey, good tip.. I'll check that one out. Thanks! Shawn > From: "Wheelock, Michael D" <[EMAIL PROTECTED]> > Reply-To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > Date: Tue, 8 Jul 2003 12:40:52 -0500 > To: [EMAIL PROTECTED] > Subject: Re: LTO throughput - real world experiences > > Hi, > > If you have fibre connected LTO drives, one really simple way is to connect > to the web console of the switch and monitor the performance of the ports on > the switch. This isn't easily automatable, but it is a very accurate > representation of what you are seeing in terms of throughput. > > Michael Wheelock > Integris Health of Oklahoma > > -Original Message- > From: Shawn Price [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 08, 2003 12:36 PM > To: [EMAIL PROTECTED] > Subject: Re: LTO throughput - real world experiences > > > What is the best way to determine what your throughput is for each process? > Are you just going by the activity log? > > Thanks! > > Shawn > >>>> [EMAIL PROTECTED] 07/08/03 1:34 PM >>> >> I'm curious as to what kind of MB/sec throughput people are seeing with > TSM > and LTO drives. > > It varies drastically for us based upon the objects being moved, of course. > 10-15MB/s / drive is normal for us overall. > >> How many MB/sec does a migration process produce in your environment? > > We achieve about 12-14MB/s per drive when performing migration. > >> Does anyone have any DB's streaming directly to LTO and some figures? > Appreciate any feedback > > Yes, our Exchange boxes stream nicely at about 15MB/s per drive. > > HTH! > > Chris Murphy > IT Network Analyst > Idaho Dept. of Lands > Office: (208) 334-0293 > [EMAIL PROTECTED] > This e-mail may contain identifiable health information that is subject to > protection > under state and federal law. This information is intended to be for the use of > the > individual named above. If you are not the intended recipient, be aware that > any > disclosure, copying, distribution or use of the contents of this information > is prohibited > and may be punishable by law. If you have received this electronic > transmission in > error, please notify us immediately by electronic mail (reply). >
Re: LTO throughput - real world experiences
Hi, If you have fibre connected LTO drives, one really simple way is to connect to the web console of the switch and monitor the performance of the ports on the switch. This isn't easily automatable, but it is a very accurate representation of what you are seeing in terms of throughput. Michael Wheelock Integris Health of Oklahoma -Original Message- From: Shawn Price [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:36 PM To: [EMAIL PROTECTED] Subject: Re: LTO throughput - real world experiences What is the best way to determine what your throughput is for each process? Are you just going by the activity log? Thanks! Shawn >>> [EMAIL PROTECTED] 07/08/03 1:34 PM >>> >I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. It varies drastically for us based upon the objects being moved, of course. 10-15MB/s / drive is normal for us overall. >How many MB/sec does a migration process produce in your environment? We achieve about 12-14MB/s per drive when performing migration. >Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Yes, our Exchange boxes stream nicely at about 15MB/s per drive. HTH! Chris Murphy IT Network Analyst Idaho Dept. of Lands Office: (208) 334-0293 [EMAIL PROTECTED] This e-mail may contain identifiable health information that is subject to protection under state and federal law. This information is intended to be for the use of the individual named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited and may be punishable by law. If you have received this electronic transmission in error, please notify us immediately by electronic mail (reply).
Re: LTO throughput - real world experiences
I've seen up to 45 MB/sec backuping oracle databases lan free. Of cource oracle compresses pretty well. This was seen on the brocade switch so I'm guessing its accurate. Guillaume Gilbert Conseiller - Gestion du stockage CGI - Gestion intégré des technologies TEL.: (514) 415-3000 ext 5091 Pager: (514) 957-2615 Email : [EMAIL PROTECTED] Chris Murphy <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 2003-07-08 13:34:33 Veuillez répondre à "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Envoyé par : "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Pour : [EMAIL PROTECTED] cc : Objet : Re: LTO throughput - real world experiences >I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. It varies drastically for us based upon the objects being moved, of course. 10-15MB/s / drive is normal for us overall. >How many MB/sec does a migration process produce in your environment? We achieve about 12-14MB/s per drive when performing migration. >Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Yes, our Exchange boxes stream nicely at about 15MB/s per drive. HTH! Chris Murphy IT Network Analyst Idaho Dept. of Lands Office: (208) 334-0293 [EMAIL PROTECTED]
Re: LTO throughput - real world experiences
What is the best way to determine what your throughput is for each process? Are you just going by the activity log? Thanks! Shawn >>> [EMAIL PROTECTED] 07/08/03 1:34 PM >>> >I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. It varies drastically for us based upon the objects being moved, of course. 10-15MB/s / drive is normal for us overall. >How many MB/sec does a migration process produce in your environment? We achieve about 12-14MB/s per drive when performing migration. >Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Yes, our Exchange boxes stream nicely at about 15MB/s per drive. HTH! Chris Murphy IT Network Analyst Idaho Dept. of Lands Office: (208) 334-0293 [EMAIL PROTECTED]
Re: LTO throughput - real world experiences
>I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. It varies drastically for us based upon the objects being moved, of course. 10-15MB/s / drive is normal for us overall. >How many MB/sec does a migration process produce in your environment? We achieve about 12-14MB/s per drive when performing migration. >Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Yes, our Exchange boxes stream nicely at about 15MB/s per drive. HTH! Chris Murphy IT Network Analyst Idaho Dept. of Lands Office: (208) 334-0293 [EMAIL PROTECTED]
LTO throughput - real world experiences
I'm curious as to what kind of MB/sec throughput people are seeing with TSM and LTO drives. I realize your mileage may vary and that it depends on your configuration but lets face it most of us have somewhat similar environments. A disk pool and tape pool. A mixture of file system data as well as database data. How many MB/sec does a migration process produce in your environment? Does anyone have any DB's streaming directly to LTO and some figures? Appreciate any feedback Gerald Wichmann Senior Systems Development Engineer ZANTAZ, Inc. 925.598.3099 (w) This e-mail has been captured and archived by the ZANTAZ Digital Safe(tm) service. For more information, visit us at www.zantaz.com. IMPORTANT: This electronic mail message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone or directly reply to the original message(s) sent. Thank you.
