Veritas-bu

[Veritas-bu] Performance Problems

2007-01-13 16:17:02
Subject: [Veritas-bu] Performance Problems
From: bob944 at attglobal.net (bob944)
Date: Sat, 13 Jan 2007 16:17:02 -0500
> I'm finally getting around to performance tuning the new 
> hardware and my hair is now officially on fire.  To say
> the storage is slow, is like saying the south pole is
> chilly.  Performance is TERRIBLE.  Not just in Netbackup,
> but generally speaking I can't copy files to these 
> volumes at >30MB/sec. [...]
> 
> Windows 2003 MP1
> Dell PowerEdge 2950s
> SATAII Drives
> NTFS compression on DSUs
> 14 Disk Raid5 array

A PC.  Running Windows.  On consumer-grade drives.  Writing to RAID 5.
With a compressed filesysstem!

Jeez, who specced out _that_ setup?  :-)  No offense, but that's a great
platform for hosting a library of .mp3s.  All of those choices are
"saving money [initially]" choices; none of them are performance
choices. 

Filesystem compression?  I wish you were kidding.  That's something to
use on a laptop when you can't get a bigger drive.  I can't think of a
single instance in my career where I've seen software compression used
in a business application where performance was any consideration.  

RAID 5 is what a business uses when money is more important than time.
Writing to RAID 5 is slow for all but idealized writes--it's the
worst-possible configuration for a DSU.  And if you're compressing that
64KB you're sending to the drives, it's not 64KB any more, so any
possibility that the stripe size might be right and avoid a R-A-R write
is gone.

SATA.  There are reasons that the "same" SCSI drives cost more (easy to
find tech discussions on the Web); high failure rates for SATA among
them.  Good choice for a home PC, maybe.

If you can get write performance and reliability that you can live with
out of this setup, great.  If not, upgrading _anything_ in this config
(say, to BSD or Solaris or Linux, to a non-PC platform, to SCSI or fibre
drives, to RAID 1 or 10 or anything but 5, to enough drives space to
forget about compression and RAID 5) will help.

> 4 - From some perspectives it looks just like the hardware 
> isn't moving
> data fast enough.  But I guess its also fair to say that NBU isn't
> driving the hardware to move the data any faster.  With the 

No offense, but that's silly.  If your backup data is being read from a
card reader, you think it's "fair to say that NBU isn't driving the
hardware to move the data any faster[?]."

> exception of
> Buffer settings is there anyway to shift the NBU I/O realted processes
> into "high gear?" Increasing the buffer sizes and adding more buffers
> only help until a certain point.

I see Ed Wilts already addressed NetBackup.  Your platform is a dog [I
said that, not Ed]; optimize or replace it first, then worry about the
apps that depend on the platform's performance.  You will find some help
in the NetBackup Performance Tuning Guide, as it walks you through
non-NetBackup methods of evaluating buses and bandwidth and testing I/O
locally and over a network so you can see what your configuration is
capable of and where it needs to be fixed.

Regarding buffer settings, when you get to that point.  To me, it's
helpful to always keep in mind that NetBackup essentially does one
thing:  read data from one place and re-write it somewhere else.  Not
much in the way of processing, formatting, manipulating--just read from
A, write to B, repeat; it's speed-limited by the side with the slower
hardware/drivers/software.  All buffers do--all buffers _can_ do in any
assembly-line situation--is provide a, um, "buffer" between A and B to
eliminate or consolidate any "bursty" behavior of A or B.  Fix A.  Fix
B.  Repeat until the slower one can't go any faster.  _Then_ figure out
what buffering is needed to help the faster one live with the slower.



<Prev in Thread] Current Thread [Next in Thread>