On Friday 20 April 2007, dustin AT zmanda DOT com wrote:
>On Fri, Apr 20, 2007 at 01:12:22PM -0400, Gene Heskett wrote:
>> In watching the write traffic into /dev/hdd, where my vtapes are located,
>> I'm seeing, particularly for the larger sized dle's, a write pattern that
>> resembles a picket fence in the gkrellm display.  I have 60 some GB of
>> holding disk, the reserved is set for about 30%, and the largest dle is
>> less than the size of a vtape as set in the tapetype. Total data is about
>> 46GB.
>>
>> It seems to me that when a dle has been collected into the holding disk,
>> then a taper should fire up and just dma the data from the holding disk to
>> the vtape, but I'm seeing writes of less than 10KB, interspersed with
>> 55MB, reported by the gkrellm utility display.  hdparm says the disk is
>> about a 75MB/Sec disk.
>
>Unfortunately, it's not practically possible to "just dma the data"..
>We looked into a few reasonably portable ways to get the kernel to
>accelerate disk transfers (O_DIRECT, various madvise flags), and the
>results were fairly inconclusive.
>
>> How best can I troubleshoot this?
>
>Well, first, you shouldn't expect to get anywhere near the platter speed
>of your disk, particularly with ext3 or its brethren.  I hear that XFS
>is capable of higher speeds, but that's unconfirmed and I've never used
>it.  For ext3, somewhere around 40-50MB/s is probably the maximum sustained
>write-only bandwidth you'll see (based on my experience).
>
>You say that both your holding disk and your vtapes are on the same
>drive.  That means that reading from one and writing to the other
>requires the drive to seek between the relevant files, which is going to
>be *very* slow.

And moving the holding disk would only be to another disk on that same cable, 
only marginally faster.  It would save the seek time, but that's about it.

>I'm not sure exactly what gkrellm is measuring (individual write() calls
>or total writes over a certain period?).  The two suggestions I have
>are:

Apparently its doing a tally at approximately 1 second intervals.

> - use 'iostat' instead as a rough IO measurement tool
> - annotate the amanda source to call dbprintf() at the relevant read()
>   and write() calls, along with the sizes requested and actually
>   performed.
>
>I think the bottom line is: this might be an interesting exercise, but
>will probably not lead to any substantial proposed changes in amanda.

That's what I was afraid of.  I have the memory buffer set at 90, and since 
I've got a gig of ram, would increasing that be of any assistance?  OTOH, I 
can do that and find the answer fairly quickly.  It will use 720 in the next 
incarnation.  90 was only a bit over 2 megs, downright puny.

>Dustin



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Finality is death.
Perfection is finality.
Nothing is perfect.
There are lumps in it.