Re: [Networker] Drive speed?

What is the purpose of tweaking the job for performance? Is the purpose
to backup asap to release your business application?

What does the backup configuration look like?
Saveset=all
or
Saveset=C:\
Saveset=D:\
Saveset=E:\
Saveset=F:\
Saveset=G:\
Saveset=H:\
Saveset=I:\

If you can't tweak the saveset/performance consider changing out the
backup device to DataDomain or Avamar?

The answer to my first question, is the justification for my last
comment above.

Semper fidelis et paratus, /ALE


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Brian O'Neill
Sent: Friday, December 09, 2011 2:52 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Drive speed?

On 12/9/2011 2:37 PM, George Sinclair wrote:
> On 2011-12-09 14:07, Chiravuri, Sri, GDH Consulting/US wrote:
>> Excellent point. If this is the case - saving same client/saveset
twice
>> (in parallel) could also bounce the thruput up ?
>
> Interesting theory. If it's true that both benefit - and, yes, I can
see
> that - then what if you were backing up 50 GB of data for a single
> stream that might otherwise take 45 minutes, let's just say. But, if
you
> instead backed the same save set up twice (in parallel), could it
still
> finish faster than 45 minutes? Hmmm ...
>
> George

It really depends on the client and network performance, but I actually 
think this won't work at all. The client couldn't keep up to the tape 
drive speed for some reason - either the disk is slow, or the I/O 
throughput of the system, or the network connection - all factors that 
probably would not change no matter how many save streams are running 
off that single box.

That, and I'm not sure how networker would react to trying to perform 
the same backup at the same time.

You are much better off trying to schedule the slower systems to run in 
parallel with other systems.

Also, even if you could do this, now you need to back up twice as much, 
and could still take longer than the ideal speed.

>
>>
>> Thx
>> Sri
>>
>> -----Original Message-----
>> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On
>> Behalf Of Brian O'Neill
>> Sent: Friday, December 09, 2011 1:04 PM
>> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>> Subject: Re: [Networker] Drive speed?
>>
>> The slow speed on the one stream is likely because your
client-to-server
>> data stream is below the minimum threshold of the tape drive to
prevent
>> it from having to write, pause, back up, spin back up to speed,
write,
>> pause, etc. So the total throughput you are seeing is low because of
the
>> time spent not actually writing data to the tape.
>>
>> The second stream brings your client-to-server data throughput over
the
>> minimum of the drive, so the tape drive doesn't have to stop, rewind,
>> start again, lather, rinse, repeat.
>>
>> Both streams should be benefitting - the first stream was penalized
by
>> flow control while the server waited for the tape drive. Now it
doesn't
>> need to.
>>
>> On 12/9/2011 10:51 AM, George Sinclair wrote:
>>> A basic question here on drive speed, but maybe not a simple answer
as
>>
>>> there are undoubtedly numerous variables involved.
>>>
>>> Let's say you have an LTO-4 drive (SAS connection to the tape
library)
>>
>>> with a single stream (one save set) clocking in around 4-10 MB/sec,
>>> coming in over the network. You then start another backup (also a
>>> single
>>> stream) from the same client to the same drive, and now it jumps up
to
>>> 70+ MB/sec, and remains at that speed until that second save set
>>> completes, and then quiets down to 4-10 MB/sec again. I've seen this
>>> happen with a number of other streams, too, wherein running just one
>>> of them from that same client, concurrent with the already running
>>> stream, cranks the speed up considerably, until it's done, at which
>>> point the original stream is reported again to be running at the
same
>> slow pace.
>>>
>>> We all know that a drive will come closer to performing optimally
when
>>
>>> you can keep it streaming, and you can do that by keeping its buffer
>>> full. OK, so having more concurrent streams - up to a point - will
>>> improve drive performance, BUT does it affect the speed at which the
>>> slow stream runs?
>>>
>>> In other words, when the reported write speed jumps up to 70+ MB/sec
>>> because you're now sending another stream (possibly one that
>>> compresses well), is the original stream (possibly one that does not
>>> compress so
>>> well) now increasing its write speed as a result? Or is it instead
the
>>
>>> case that while the drive is now functioning more optimally, and
>>> writing more data per second, that first (slow) stream is still
>>> clunking along at its original speed, and sending more streams will
>>> not increase the speed of any one of them?
>>>
>>> I'm inclined to think that the increase in speed is only affecting
the
>>
>>> additional stream(s) and not that original one.
>>>
>>> Thanks.
>>>
>>> George
>>>
>>
>> To sign off this list, send email to listserv AT listserv.temple DOT edu and
>> type "signoff networker" in the body of the email. Please write to
>> networker-request AT listserv.temple DOT edu if you have any problems with
this
>> list. You can access the archives at
>> http://listserv.temple.edu/archives/networker.html or via RSS at
>> http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>>
>
>

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER