Tru64 NetBackup Performance

[Rob Leadbeater]

You appear to have far too many tape devices on the GS1280 for a 12 drive library...

Can you also post the output of:

# hwmgr show scsi -full


Cheers,

Rob

[hkyeakley]

OK, on the tape drives.

I have a NetApp VTL and I have about 100 virtual drives presented to my systems.

The difference between the VTL drives and the real drives is that the real drives have a firmware revision of 94D0 and the NetApp virtual drives have a "firmware" revision of 022C.

So yes, the system does see about 120 tape drives, but all of them only write at about 10 MB/s - 20 MB/s.

Do you still want the output of # hwmgr show scsi -full?

[cnb]

Maybe run the latest syscheck version (145)on the 'good' and 'suspect' systems and compare results?

Rgds,

[Bondarenko Alexander]

"You mention streaming to tape instead of start/stop mode. I'm not sure I understand that question."
It's rather simple: If system for some reason could not supply data to tape so fast as it compress and write to media, device buffer become empty and tape will stop. Unfortunatelly drive stop tape somewere after end of recorded data, so it's need to rewind and search EndOfRecord mark before next portion of data could be written. Huge seek time delay.
So it's need supply data as fas as 120Mb/s if compression enabled. If bottleneck are somewere and only 80Mb/s could be provided, tape drop to start/stop mode with speed 10-20Mb/s.
"quad" - each 4 switch ports are run on one IC. For example for Brocade ports 0,1,2,3
used by FCA1,Eva1,FCA2,Eva2. Next quad ports 4,5,6,7 are used by tape routers, we will get bottleneck at switch backplane.
From Tru64 side if you have about 1Gb free memory and backup SW use large block or good blocking factor, it's not unix problem.
You could check dataflow by dd local SCSI to tape. UltraSCSI 160Mb/s and dd with 1Mbyte block give good checking.

[Rob Leadbeater]

Hi,

> Do you still want the output of # hwmgr show scsi -full?

Yes please...

Another thought... have you tried running backups with something like vdump to rule out any issues with NetBackup ?

Cheers,
Rob

[hkyeakley]

I'm attaching the output of hwmgr show scsi -full

Sorry I've been quiet on this topic. I really do appreciate everyone's input on this topic.

Someone mentioned that LTO-4 is not supported on Tru64. According to IBM's documentation, that's correct. However, LTO-3 is supported. Shouldn't Tru64 autonegotiate and at least run at LTO-3 speeds? Even if all I was getting was 60MB/s - 80MB/s, that still beats the 10MB/s - 20MB/s that I am getting.

Furthermore, that still doesn't explain why my ES80 at my DR site gets blazing speeds.

While doing some research on Google trying to find a solution to my slow backup and restore issues on Tru64, I stumbled across the following white paper:

http://bit.ly/b5XuwL

Is that my problem? In order to get performance out of my 8 HBAs going to my library, do I need to use the runon command to specify which QBB or processor my backups run on? That seems a bit convoluted to me.

Again, I greatly appreciate any assistance everyone can be in solving this issue.

Thank you.

[Bondarenko Alexander]

You are find right white paper, but one difference GS1280 more better than GS320/160/80. You not need use "runon" so much as it is on above paper.Interprocessor mesh GS1280 so powerfull that aplift from "runon" is not so huge. All other topics are very important: zoning-mapping, HBA place at PCI box, data flow across switches...