Much appreciated once again everyone for the response on this topic, the
info has certainly made things a lot clearer.
Additionally I have run some bpbkar32 tests to NULL and it would appear
in some instances the server is struggling to provide the data.
Cheers again
Dave
________________________________
From: Brenton Carbins [mailto:brenton_carbins at symantec.com]
Sent: 16 October 2006 14:54
To: Clooney, David
Subject: RE: [Veritas-bu] 9940B
Hi David,
The issue with changing SIZE_DATA_BUFFERS is something like this. My
knowledge is empirical, so the exact causes may be a little different:
When media of 100GB is labelled with a block size of 100k, the label (or
perhaps media.db) records a clock count of 1,000,000. So we write
500,000 blocks with a 100k block size, and then change the block site to
200k. The recorded remaining block count is 500,000, but in practice, it
is now only 250,000. But NetBackup will happily append the tape, until
it has written a further 250,000 blocks. On the 250,001st block, there
is no tape left, and we get a 174 Error. Basically, the time taken to
write the 250,000 blocks (at 200k/block) is lost, as the job will have
to restart, or perhaps fail, according to job configuration, window,
etc.
Therefore, in order to avoid 174 errors, the media recorded with a block
size of 100k cannot be rewritten with 200k blocks until they have been
relabelled. Now, change the numbers to reflect actual SIZE_DATA_BUFFERS,
and the maths still holds.
I have attached a note that I wrote some years ago, but have found
generally useful up to version 5.1. Perhaps the most helpful will be the
last page. Please note also I have had 9940B drives averaging 55-60MB/s,
peaking at 70MB/s with one customer, and these same tuning notes have
been used to obtain over 100MB/s with VTLs at another site.
I trust this is of some help to you.
Brenton
________________________________
Brenton Carbins
Senior Systems Engineer
WA and SA Enterprise Products
Symantec Corporation
www.symantec.com <http://www.symantec.com/>
-----------------------------------------------------
Office: 08 9480 3720
Mobile: 0409 779 230
Fax: 08 9481 3177
Email: Brenton_Carbins at symantec.com
-----------------------------------------------------
Compelling New Features
Low Bandwidth, Remote Office Backup
http://www.symantec.com/Products/enterprise?c=newfeatures&refId=1381
________________________________
From: Clooney, David [mailto:david.clooney at bankofamerica.com]
Sent: Monday, 16 October 2006 6:08 PM
To: Brenton Carbins
Cc: veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] 9940B
Much appreciated for the response Brenton
I have performed some tests after analysing bpbkar and bptm logs all all
media servers and a number of their bptm logs indicate that they are not
waiting for empty buffers, in turn telling me that an increase of the
buffer size and number should have a positive impact .
After testing our throughput has jumped around from around 11mb/sec to
40+ mb/sec which is fantastic, my concern is for the latter part of your
mail regarding tapes which have been written with a different
SIZE_DATA_BUFFERS.
When testing I took backups before and after the SIZE_DATA_BUFFERS
implementation. I then proceeded to test restores from both images
written with different Buffer sizes.
All where successful however could you shed a little more light on this
as we obviously have all our backed up data written in the current
SIZE_DATA_BUFFER and it would be a shame not to achieve the throughput
we saw when testing.
Thanks in advance
Dave
________________________________
From: Brenton Carbins [mailto:brenton_carbins at symantec.com]
Sent: 16 October 2006 01:32
To: Clooney, David
Subject: RE: [Veritas-bu] 9940B
Hi David,
My clients running 9940B drives are all running a SIZE_DATA_BUFFERS of
262144, with NUMBER_DATA_BUFFERS less important, and dependent on system
resources and kernel settings. I'd suggest 32-64 buffers if you can
achieve this without Error 11s. It is important when you are changing
these settings that you test with maximum anticipated multiplexing and
the maximum anticipated number of drives running, so that resource usage
will hit it's peak, and any problems detected immediately.
If you already have lots media written with a different SIZE_DATA_BUFFER
- say 131072, it is probably better not to change this value. If you do
change this value, you will need to re-label existing media before
attempting to write to them again. This may require that you suspend
media until existing images expire.
Best of luck,
Brenton
________________________________
Brenton Carbins
Senior Systems Engineer
WA and SA Enterprise Products
Symantec Corporation
www.symantec.com <http://www.symantec.com/>
-----------------------------------------------------
Office: 08 9480 3720
Mobile: 0409 779 230
Fax: 08 9481 3177
Email: Brenton_Carbins at symantec.com
-----------------------------------------------------
Compelling New Features
Low Bandwidth, Remote Office Backup
http://www.symantec.com/Products/enterprise?c=newfeatures&refId=1381
________________________________
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Clooney,
David
Sent: Friday, 13 October 2006 6:09 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] 9940B
Hi
Was wondering whether anyone knows the max I/O buffer size for the STK
9940B ?
Trying to fine tune some media servers using the SIZE_DATA_BUFFERS and
NUMBER_DATA_BUFFERS.
And was thinking the drive would obviously determine what the settings
should be.
Regards
Dave
________________________________
Notice to recipient:
The information in this internet e-mail and any attachments is
confidential and may be privileged. It is intended solely for the
addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to
be taken in reliance on it, is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in
this internet e-mail are subject to the terms and conditions expressed
in any applicable governing terms of business or client engagement
letter issued by the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch and Banc of America Securities Limited are
authorised and regulated by the Financial Services Authority.
________________________________
________________________________
Notice to recipient:
The information in this internet e-mail and any attachments is
confidential and may be privileged. It is intended solely for the
addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to
be taken in reliance on it, is prohibited and may be unlawful.
When addressed to external clients any opinions or advice contained in
this internet e-mail are subject to the terms and conditions expressed
in any applicable governing terms of business or client engagement
letter issued by the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America,
N.A., London Branch and Banc of America Securities Limited are
authorised and regulated by the Financial Services Authority.
________________________________
Notice to recipient:
The information in this internet e-mail and any attachments is confidential and
may be privileged. It is intended solely for the addressee. If you are not the
intended addressee please notify the sender immediately by telephone. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may be
unlawful.
When addressed to external clients any opinions or advice contained in this
internet e-mail are subject to the terms and conditions expressed in any
applicable governing terms of business or client engagement letter issued by
the pertinent Bank of America group entity.
If this email originates from the U.K. please note that Bank of America, N.A.,
London Branch and Banc of America Securities Limited are authorised and
regulated by the Financial Services Authority.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061016/7ca63f09/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2653 bytes
Desc: sigGenLogo.jpg
Url :
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061016/7ca63f09/attachment-0002.jpeg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2653 bytes
Desc: sigGenLogo.jpg
Url :
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061016/7ca63f09/attachment-0003.jpeg
|
