Amanda-Users

Re: sendsize finishes, planner doesn't notice...

2007-10-12 15:53:22
Subject: Re: sendsize finishes, planner doesn't notice...
From: Paul Lussier <pll+amanda AT permabit DOT com>
To: Jean-Louis Martineau <martineau AT zmanda DOT com>
Date: Fri, 12 Oct 2007 15:47:03 -0400
Jean-Louis Martineau <martineau AT zmanda DOT com> writes:

> Paul Lussier wrote:
>>> You should add a spindle for dle on the same physical disk, it can be
>>> a lot faster.
>>>     
>> I don't understand this statement.  Could you clarify please?
>>   
> man amanda
> search for spindle
> All DLE of a physical disk should have the same spindle (>0).
> It's generally faster to run them sequentially instead of in parallel,
> just think about head movement.

Ahh, right, I've been down that route before.  This system is an NFS
appliance like a NetApp containing ~5TB striped across a single RAID5
array.  In this case, head movement (i.e. thrashing) isn't an issue.

Consider for a moment, an NFS server with 20 exports all on the same
"spindle" being accessed simultaneously by several hundred clients.
Since the specs on this file server are supposed handle this scenario,
having 1 of those clients doing simultaneous recursions of all it's
exports should hardly put any stress on the system.

In fact, when I had spindles set on the individual DLEs such that the
backups occurred sequentially, the estimate was taking far longer than
it is now.  Currently the estimates for these DLEs in parallel are at
about 9 hours.  Sequentially we were looking at somewhere close to 35.

Several of those DLEs are up around 500-600GB each, and therefore
*each one* takes close to 9 hours.  The aggregate time when done
sequentially is 9n, where n=# of DLEs of that similar size.

I think in parallel is fine, we just need to get the amandad and
sendsize to cooperate.

>> Are you suggesting this is currently possible, or that it might be a
>> good solution for the future? 
>
> for future.

That's what I suspected.  

Thank you for all your help.  I've recompiled with a higher
REP_TIMEOUT (15) and am re-running the test to be sure that's it.

Provided I don't run into any more problems after that, I'll likely
set my estimates to 'calcsize' for the next test and see what happens.

-- 
Thanks,
Paul

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