Re: amanda performance
2005-12-16 12:17:33
On Friday 16 December 2005 11:42, Joshua Baker-LePain wrote:
>On Fri, 16 Dec 2005 at 9:22am, Roy Heimbach wrote
>
>> We have amanda 2.4.5p1 server running under debian linux on a dual
>> opteron that's driving a new overland tape library with an ultrium3
>> drive. For now, the holding disk is a dedicated local 120 GB
>> drive.
>
>A single drive is going to have an awfully hard time... scratch that.
> A single drive can *not* feed an lto3 drive as fast as it wants to
> be fed (even if that's the only thing it's trying to do). I've got
> a 4 disk hardware RAID0 feeding my lto3 drive.
Ahh, I'd argue that point Roy. Of the two active drives on this
machine, the main one is a 120GB, and I'm using a 200G as virtual
disk. These are on seperate cables of the same on board nforce2
controller. As all drives here have dma enabled, the hdparm -tT test
returns are typically in the 50-60 mb/second rate. I did have a scsi
controller in here at one time but the tape died so it was removed.
But while it was installed, I was able to get 20mg/second transfers to
another smallish scsi drive hooked up temporarily. The drive was
rated as scsi-2-fast, as was the advansys controller.
If this user is only getting 2.5mb/sec, something is wrong with the
config someplace. I'd start with the hdparm -Tt /dev/whatever tests
and see if the dma can be enabled all across the board.
>> There's an amanda 2.4.5p1 client also running under debian linux on
>> another dual opteron that's connected to the amanda server host via
>> a dedicated gig network. This host is a moderately loaded
>> fileserver with hardware raid.
>>
>> Backing up a 10 GB test partition, we're seeing dumper and taper
>> performance around 2.5 MB/sec, a fraction of what the hardware is
>> capable of.
>
>*snip*
>
>> Any suggestions would be welcome.
>
>Priority one is to figure out where the slowdown is. Bench the
> hardware RAID with something like bonnie++ and/or tiobench. Ditto
> for the holding disk. Use tar to write /dev/zero (using your chosen
> blocksize) to the tape drive. Then, do a test amdump to holding
> disk. Amflush that dump.
Good advice as it may pin-point the bottleneck.
--
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.heskett AT verizononline DOT net> which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
|
|
|