This is a multipart message in MIME format.
--=_alternative 005C23B886256D75_=
Content-Type: text/plain; charset="US-ASCII"
veritas-bu-admin AT mailman.eng.auburn DOT edu wrote on 08/01/2003 11:34:59 AM:
>
> I'm seeing between 4 and 9 MB/sec.
>
Me Too!
I'm guessing that your not using multiplexing/multistreaming (IE: writting
2 or more jobs to the same tape drive at the same time).
Which then leads one into the performance tuning of netbackup. Which is a
fun learning curve.
Larry Kingery posted the following yesterday which opened my eyes(I liked
the part about "Avoid the common mistake of trying to "tune the buffers"")
> policy to 4. Each mount point has about 175gb of data to be backed
> up. The policy kicks off 4 jobs as it should, but is taking 10 to 12
> hours to complete. I looked in my bptm logs and am seeing the
> following:
>
> 05:00:51.795 [26600] <2> write_data: waited for full buffer 114308
times,
> delayed 131449 times
>
> 05:06:11.186 [26608] <2> write_data: waited for full buffer 117920
times,
> delayed 138141 times
>
These messages tell us that the tape drive had to stop writing a
number of times and wait for the input to catch up. You can't really
quantify the amount of time based only on the above, except to say it
was at least an hour in total. This gives us a clue as to where to
start looking to improve performance.
You don't mention whether this is a media server or client, network
speed, use of mpx, etc. I suppose the place to start then would be to
measure how quickly the data can be read from disk.
# time ./bpbkar -dt 0 -r 8888 -nocont DISK-PATH > /dev/null
You'll probably want to try running this in various combinations
(e.g. one for each filesystem, concurrently and separately) to find
the best performance combination. Also you might compare this to
using dd to read raw disk to analyze filesystem overhead.
>From there, assuming you can get better than 10-12 hours, move on to
analyze network, etc.
Avoid the common mistake of trying to "tune the buffers". For
example, you COULD decrease the buffer size and probably make these
numbers go down. However, all that would be doing is slowing the tape
drives down to the level of input. This would make no performance
difference, which is really what you're after.
--=_alternative 005C23B886256D75_=
Content-Type: text/html; charset="US-ASCII"
<br>
<br><font size=2><tt>veritas-bu-admin AT mailman.eng.auburn DOT edu wrote on
08/01/2003
11:34:59 AM:<br>
<br>
> </tt></font>
<br><font size=2><tt>> I'm seeing between 4 and 9 MB/sec. </tt></font>
<br><font size=2><tt>> </tt></font>
<br>
<br><font size=2><tt>Me Too!</tt></font>
<br>
<br><font size=2><tt>I'm guessing that your not using
multiplexing/multistreaming
(IE: writting 2 or more jobs to the same tape drive at the same
time).</tt></font>
<br>
<br><font size=2><tt>Which then leads one into the performance tuning of
netbackup. Which is a fun learning curve.</tt></font>
<br>
<br><font size=1 face="sans-serif"><b>Larry Kingery</b></font><font size=2><tt>
posted the following yesterday which opened my eyes(I liked the part about
"Avoid the common mistake of trying to "tune the
buffers"")</tt></font>
<br>
<br><font size=2><tt>> policy to 4. Each mount point has about
175gb of data to be backed<br>
> up. The policy kicks off 4 jobs as it should, but is taking 10 to
12<br>
> hours to complete. I looked in my bptm logs and am seeing the<br>
> following:<br>
><br>
> 05:00:51.795 [26600] <2> write_data: waited for full buffer
114308 times,<br>
> delayed 131449 times <br>
> <br>
> 05:06:11.186 [26608] <2> write_data: waited for full buffer
117920 times,<br>
> delayed 138141 times <br>
> <br>
<br>
These messages tell us that the tape drive had to stop writing a<br>
number of times and wait for the input to catch up. You can't really<br>
quantify the amount of time based only on the above, except to say it<br>
was at least an hour in total. This gives us a clue as to where to<br>
start looking to improve performance.<br>
<br>
You don't mention whether this is a media server or client, network<br>
speed, use of mpx, etc. I suppose the place to start then would be
to<br>
measure how quickly the data can be read from disk.<br>
<br>
# time ./bpbkar -dt 0 -r 8888 -nocont DISK-PATH > /dev/null<br>
<br>
You'll probably want to try running this in various combinations<br>
(e.g. one for each filesystem, concurrently and separately) to find<br>
the best performance combination. Also you might compare this to<br>
using dd to read raw disk to analyze filesystem overhead.<br>
<br>
>From there, assuming you can get better than 10-12 hours, move on to<br>
analyze network, etc.<br>
<br>
Avoid the common mistake of trying to "tune the buffers".
For<br>
example, you COULD decrease the buffer size and probably make these<br>
numbers go down. However, all that would be doing is slowing the
tape<br>
drives down to the level of input. This would make no performance<br>
difference, which is really what you're after.</tt></font>
--=_alternative 005C23B886256D75_=--
|
