Thanskl for all who delivered suggestions for this:
>>> To really know how fast your dumps are going, look down the KB/s
>>> column. Your numbers look pretty good to me. You've got better than
>>> 1 MB/s on all your big dumps.
>> True.
>> The point is though that 2.3M/s (which Im getting at the 0 dump of the
>> biggest one) translates to about 10G/hr, which means it takes 11 hours to
>> dump the largest slice.
> Wow, that's one big partition. You _could_ cut it up into smaller
> partitions or use the GNU tar top level directory trick but you
> probably have your reasons why those solutions won't work for you.
OK,
maybe a description of th setup might help.
We've got 1 (one) big server (sun UE450)
it's got 2 scsi ontrollers, and we stuck in an additional 2 dual scsi cards
giving us 6 scsi channels.
They're all ultra LVD (that's 160 Mbaud unles Im deeply mistaken )
Controller 0
-> 4 internal 4 G disk
1 disk split up into different slices
other 3 disks striped to a 12 Gb disk
Controller 1
-> CDrom drive
-> Mammoth tape drive
-> Mammoth tapedrive
Controller 2
-> empty
Controller 3
-> 2 18G disks
-> 1 36G disk partitioned into 2 18G disks
Controller 4
-> LTO tapedrive
Controller 5
-> Zero downtime RAID array (420 G)
[this puppy rules, see below for rant ;) ]
For the 420G raid array I use gnutar (and a patched sendsize to use
calcsize to calculate the estimates, see my previous posts on this)
to backup the toplevel subdirs.
The RAID array is raid 5 (w/ hotspare).
The holding disk is on that same raid array (and on the same partition)
I've checked, and it's not the scsi controller bandwidth that's the
limiting factor.
[that is, if amdump is dumping to holding disk, I can start moving data to
and from that disk, whitout the amdump performance dropping noticably]
* Johannes Niess <[EMAIL PROTECTED]> (Thu, Feb 01, 2001 at 08:01:39PM +0100)
> Let's do the math:
> We need 10 M/s sustained transfer rate from holding disk to the tape
> and 10 M/s from data disk to holding disk. A 80 M/s SCSI bus should be
> able to do that.
> 20 M/s with a lot of seeks are quite a load for a single holding
> disk. Depending on you holding disk hardware I'd guestimate 3 M/s a
> reasonable throughput under these circumstances.
Im getting 7 M/s to tape, while the simultaneous write to the holding disk
is around 3 M/s
Even if there are 2 dumpers dumping (giving 6 M/s -> holding disk) I easily
get 7 M/s to tape.
I upped maxdumpers to 4
and rearranged the toplevel dir layout on the big disk (i split the 110G
dir into 2 dirs of ~ 55G each).
Let's see how weel that performs ..
If upping maxdumpers to 4 is indeed bottlenecking the disk
(which i can easily see if the dumper speed average is dropping instead of
staying more or less the same) I can lower the number again.
> Nobody asked about seek problems on your data disks. It definitely
> kills performance to dump two partitions of the same disk at the same
> time. Amanda's default value of the spindle parameter is not at an
> intuitive value:
Been there, tried that, sent the postcard ;)
dumping a single disk at once gives me roughly the sme performance as
dumping 2 disks simultaneously, even to the same holding disk.
> Johannes Niess
> P.S: Feel free to make a faq-o-matic section on performace out of
> this. What about a weekly post of the FAQ to this list?
I am actually keeping notes on this, and I plan to put it all together into
some larger document.
Im proobaly gonna stick it on my webpage (along with all the other useful
hints and tips I've found about amanda sofar).
Ill happily make it into a faq-o-matic or write it up a bit more detailed
for inclusion with the amdna docs.
Whatever is most appropriate.
(but currently i's not yet finished ,
and im still experimenting.
Gerhard, <@jasongeo.com> == The Acoustic Motorbiker ==
--
__O Standing above the crowd, he had a voice so strong and loud
=`\<, we'll miss him
(=)/(=) Ranting and pointing his finger, At everything but his heart
we'll miss him
