LTO4 tapes not fatser than LTO2

[Andrew Pollard]

Hi,

We have an IBM 3584 library connected through a SAN to an RP8400 UNIX server running HPUX 11.23. We have a home grown script that uses ftio to perform our backups, writing to LTO2 tape drives. We are moving to using LTO4 tape drives but when we perform bench mark tests, we are not seeing an increase to performance and in some cases, the backup to LTO4 is taking longer than to LTO2 drives.

Is anyone else experiencing this? Are there any patches that are required either for ftio or SCSI cards in order to see faster performance?

Any help would be great.

Thanks

Andrew

[Torsten.]

Did you also measure the source of the data?

If the data source is slow, the tape can also write slow only.

[Andrew Pollard]

Hi Torsten,

The source of the data is exactly that same as it is during our current backups using LTO2 drives, That is why we were expecting to see faster backups to the newer hardware. For example, a backup that took 7 hours 30 minutes to write to the LTO2 drive took 7 hours and 32 minutes to write to the LTO4 drive.

Andrew

[Víctor Cespón]

You could be limited by the speed at which the server can read data from the disks or can send it to the library.

Download Library and Tape Tools, and run performance tests. It uses data generated on RAM so that side will not be the limit.

[Torsten.]

So its exactly the same time. You need to investigate if the data source is already at 100% or if it can deliver data faster. Question is: where is the bottleneck?

[TTr]

> a backup that took 7 hours 30 minutes to write to the LTO2
I am very curious to know how much data you backed up in that time with the LTO2 drive. Did you really approach the LTO2 streaming capability? Why did you decide to upgrade to LTO4? As others mentioned, the problem is not on the drive it could be on any of the other areas that the data passes through to get to the tape. It can be on the disks, on the server (i/o), on the i/o interface etc.
The LTO4 drive is faster than the fastest disk (except solid state disks), so you will never be able to keep the lto4 busy with just a single stream of disk traffic. In fact I don't think it is easy to flood an lto2 drive with a single disk stream. Does your application do any multistreaming?

[Andrew Pollard]

Hi,

We backed up the exact same data during both the back up to LTO2 and the back up to LTO4, the total amount was 482GB. We are moving to LTO4's because of the hardware encryption it provides, but we are not using the encrytion yet and it was not turned on during these tests.

We would like to use perfview to collect some performance data from the backups, can you suggest a matrix that we can use to collect the correct data?

Thanks

Andrew

[Torsten.]

It could depend on all areas, as mentioned ...


One of the first question would be about the layout.

You said all is on SAN. How many FC HBAs are in use? How fast they are? Do you run the backup over the same FC HBA to both libs? How about the data source? Also the same FC HBA? etc ...

[TTr]

482GB in 7hr30min is 17.8MB/sec. The LTO2 is 30MB/s native (not compressed). Depending on the compressibility of the 482GB the LTO2 the 17.8MB/s is probably much less. So the tape was never the issue here. Check all areas mentioned above for any bottlenecks. The rp8400 is a powerful server, you should be doing better than that.

You can actually run some tests with ftio using a disk file or /dev/null instead of the tape device. You should then see how the reading is done by monitoring the areas that are read and the amount of data written to /dev/null or to a disk file.

[Andres_13]

Hi

I have two old Ultrium 6-60 tape libraries which last sunday backed up about 980 Gb in 3:30 hrs. using 4 LTO-1 drives, with Data Protector 6 on a client running HP-UX 11.00 all thru SAN.

I also think that your bottleneck is not in your drives. I'd rather think that you hava a serious problem with the data transfer from your server to your drives. HP's LTT it's a good tool for testing purpouses.