Performance

[Alexander Pino, Sr.]

Just recently, my company purchased an L-class server and on that server we installed OmniBackII. Despite my "entry-level" experience with both HP and UNIX (formerly an 20 Yr. IBM Mainframe experience), I'm told I'm doing "better than adequate job." Needless to say, there's a ton of learning.

My major concern at this time is that one of my backups take anywhere from 12 to 17 hours to complete. This is a "host" backup over the network. Is there anything I can do to determine that this is not a "network issue"? All responses are greatly appreciated.

[Berlene Herren]

If you have 100BaseT cards, make sure you do not have a duplex mismatch. The preferred method is to turn off autonegotiation on both the switch and the card and hard set the duplex. I attached a whitepaper that explains this.

Ensure you have the latest LAN, ARPA, STREAMS, Omniback patches and patches associated with your lan card.

To determine throughput, you can download netperf and run that, then compare it with the speeds listed in the database on that page.

http://www.netperf.org.

Hope this helps!

Berlene

[Bill Hassell]

12 to 17 hours is excellent performance if you are backing up 10 or 15 terabytes. Seriously, look at the amount of data first, then figure about 30-40% loading of the LAN speed and do the math. 100BaseT can do a FEW megabytes per second, way less than disks. So if the network was nothing more than a peer-to-peer wire, you still might not see much better performance.

On the other hand, performance that is signifcantly below the rated speed of the LAN may mean delays in getting the data from the client and onto the server, plus data starvation for streaming tapes...each reposition will consume a lot of time with zero bytes per second.

And finally, there's the health of the LAN itself. A single rogue laptop on the net that has every (silly PC) protocol enabled can generate a UDP flood of noise which will mash your throughput into the cellar.

[Greg Porter_1]

We recently installed OB for the first time, and had serious performance issues as well. We tried this, that, and the other, but nothing made a significant difference until we explored trying to stream the drive. A single (or even 2 or 3) K-Class servers going full tilt at 100Base-T can't throw data fast enough to keep a single DLT7000 happy (at least in our environment). Apparently the drive gets bored, and falls asleep until it's buffer fills up, then it has to go through some elaborate waking ritual. This means that it is IMPERATIVE that you throw LOTS of data at the drive, or your performance goes into the crapper.

I went from 1 K-Class backing up 3 GB in 30 mins to
6 K-classes backing up 30 GB in 70 mins. That's a hell of a difference. We fiddled with segment size, block size, concurrency, blah, blah and they didn't matter a hill of beans.

Try throwing data from multiple hosts at it simultaneously.

Good luck.

[Alexander Pino, Sr.]

Thank you all very much for your help.

Here's the deal. The infamous backup was taking 12 - 17 hours, despite it only being approximately 60GB, it was going across the net-work at a rate of 10MgBits.