Queston re NET_BUFFER_SZ... - Veritas Net Backup
This is a discussion on Queston re NET_BUFFER_SZ... - Veritas Net Backup ; Hi Group,
Two questions...
1) How many instances of "net_buffer_sz" are created/used on a media server?
I've asked Symantec support if they could tell me how many instances of
"NET_BUFFER_SZ" are created on a media server. Is it one per ...
-
Queston re NET_BUFFER_SZ...
Hi Group,
Two questions...
1) How many instances of "net_buffer_sz" are created/used on a media server?
I've asked Symantec support if they could tell me how many instances of
"NET_BUFFER_SZ" are created on a media server. Is it one per server, oner
per backup job (i.e. stream), one per client, one per policy, etc...
The guy I spoke with on the phone tried talking to me about
size_data_buffers and number_data_buffers - but I know these are related to
actual tape I/O, and not to network receive I/O from clients. I'm fed up
with rubbish telephone support.
Then they said they don't know, and now they've come back with "It's one per
media server." I asked for a copy of a document that actually says this,
but nothing has been offered back.
I find it difficult to believe that *ALL* incoming data from *ALL* clients
is filtered through one network receive buffer... I'm hoping some of you
gurus out there can expand upon the answer.
2) Why would I see different sizes specified in different "network receive
buffer size is" messages in bptm log files?
My WIndows media servers are fine. The following only happens on Unix media
servers. In bptm logs, on any given day, I can see "network receive buffer
is 32120", but later on in the day (not set time this happens), I then see
"network receive buffer is 33120". Sometimes it's the other way around,
sometimes close together, sometimes upto 23 hours apart, but never with any
set order of occurence, sometimes I don't see both messages and only see one
of them (either size). Can anyone explain why this would happen?
Symantec support have actually said "It doesn't matter, don't worry about
it.". But, if my clients have 32kb buffers (i.e. 32768 bytes), then surely
it does matter if the receiving media server is using 32120? Won't the
media server have more work to do, in splitting and re-joining packets etc?
Thanks,
Dave.
-
Re: Queston re NET_BUFFER_SZ...
in article 44c09e15@ROSASTDMZ05., D R at a@b.c.d wrote on 7/21/06 12:53 AM:
> Hi Group,
>
> Two questions...
>
> 1) How many instances of "net_buffer_sz" are created/used on a media server?
> I've asked Symantec support if they could tell me how many instances of
> "NET_BUFFER_SZ" are created on a media server. Is it one per server, oner
> per backup job (i.e. stream), one per client, one per policy, etc...
> The guy I spoke with on the phone tried talking to me about
> size_data_buffers and number_data_buffers - but I know these are related to
> actual tape I/O, and not to network receive I/O from clients. I'm fed up
> with rubbish telephone support.
> Then they said they don't know, and now they've come back with "It's one per
> media server." I asked for a copy of a document that actually says this,
> but nothing has been offered back.
> I find it difficult to believe that *ALL* incoming data from *ALL* clients
> is filtered through one network receive buffer... I'm hoping some of you
> gurus out there can expand upon the answer.
>
> 2) Why would I see different sizes specified in different "network receive
> buffer size is" messages in bptm log files?
> My WIndows media servers are fine. The following only happens on Unix media
> servers. In bptm logs, on any given day, I can see "network receive buffer
> is 32120", but later on in the day (not set time this happens), I then see
> "network receive buffer is 33120". Sometimes it's the other way around,
> sometimes close together, sometimes upto 23 hours apart, but never with any
> set order of occurence, sometimes I don't see both messages and only see one
> of them (either size). Can anyone explain why this would happen?
> Symantec support have actually said "It doesn't matter, don't worry about
> it.". But, if my clients have 32kb buffers (i.e. 32768 bytes), then surely
> it does matter if the receiving media server is using 32120? Won't the
> media server have more work to do, in splitting and re-joining packets etc?
>
> Thanks,
> Dave.
>
>
It's either one per client or stream. If you're seeing a value other than
the default of 32032 then check your media server's setting at
/usr/openv/netbackup/NET_BUFFER_SZ or your windows client's setting in
registry key 'Buffer_Size' and unix client's setting at
/usr/openv/netbackup/NET_BUFFER_SZ.
-
Re: Queston re NET_BUFFER_SZ...
Thanks PS.
1) Both of the Unix media servers do not have a NET_BUFFER_SZ file defined.
So they should default to 32032. But they don't. Both media servers flip
between 32120 and 33120. The bptm logs show that they attempt to use 32032,
but Solaris 8 (or something) is telling them to use 32120 or 33120, and then
at random points later in the day they flip to the other size. Can anyone
figure this out?
I've checked xmit_hiwat (16384) and recv_hiwat (24???) and
max_tcp_buffer_size (1MB)
2) Why would a Windows client buffer size have any baring on a media servers
receive buffer size?
Thanks,
Dave.
"ps" wrote in message
news:C0E64381.146C0%fsck@smicker.com...
> in article 44c09e15@ROSASTDMZ05., D R at a@b.c.d wrote on 7/21/06 12:53
> AM:
> It's either one per client or stream. If you're seeing a value other than
> the default of 32032 then check your media server's setting at
> /usr/openv/netbackup/NET_BUFFER_SZ or your windows client's setting in
> registry key 'Buffer_Size' and unix client's setting at
> /usr/openv/netbackup/NET_BUFFER_SZ.
>
-
Re: Queston re NET_BUFFER_SZ...
to answer your question - its one per job. Veritas is designed to use minimum
resources, especially in unix machines and hence the actual value can vary
depending on the master servers' & clients capability to process. also i
assume there is an either or condition with buffer size and time taken to
create a packet.
also if your backup contains large number of small files, its recommended
to use a lower tcp buffer sizes to avoid fragmentation.
ps wrote:
>in article 44c09e15@ROSASTDMZ05., D R at a@b.c.d wrote on 7/21/06 12:53
AM:
>
>> Hi Group,
>>
>> Two questions...
>>
>> 1) How many instances of "net_buffer_sz" are created/used on a media server?
>> I've asked Symantec support if they could tell me how many instances of
>> "NET_BUFFER_SZ" are created on a media server. Is it one per server,
oner
>> per backup job (i.e. stream), one per client, one per policy, etc...
>> The guy I spoke with on the phone tried talking to me about
>> size_data_buffers and number_data_buffers - but I know these are related
to
>> actual tape I/O, and not to network receive I/O from clients. I'm fed
up
>> with rubbish telephone support.
>> Then they said they don't know, and now they've come back with "It's one
per
>> media server." I asked for a copy of a document that actually says this,
>> but nothing has been offered back.
>> I find it difficult to believe that *ALL* incoming data from *ALL* clients
>> is filtered through one network receive buffer... I'm hoping some of
you
>> gurus out there can expand upon the answer.
>>
>> 2) Why would I see different sizes specified in different "network receive
>> buffer size is" messages in bptm log files?
>> My WIndows media servers are fine. The following only happens on Unix
media
>> servers. In bptm logs, on any given day, I can see "network receive buffer
>> is 32120", but later on in the day (not set time this happens), I then
see
>> "network receive buffer is 33120". Sometimes it's the other way around,
>> sometimes close together, sometimes upto 23 hours apart, but never with
any
>> set order of occurence, sometimes I don't see both messages and only see
one
>> of them (either size). Can anyone explain why this would happen?
>> Symantec support have actually said "It doesn't matter, don't worry about
>> it.". But, if my clients have 32kb buffers (i.e. 32768 bytes), then surely
>> it does matter if the receiving media server is using 32120? Won't the
>> media server have more work to do, in splitting and re-joining packets
etc?
>>
>> Thanks,
>> Dave.
>>
>>
>It's either one per client or stream. If you're seeing a value other than
>the default of 32032 then check your media server's setting at
>/usr/openv/netbackup/NET_BUFFER_SZ or your windows client's setting in
>registry key 'Buffer_Size' and unix client's setting at
>/usr/openv/netbackup/NET_BUFFER_SZ.
>
-
Re: Queston re NET_BUFFER_SZ...
in article 44c34fd0@ROSASTDMZ05., D R at a@b.c.d wrote on 7/23/06 1:44 AM:
> Thanks PS.
>
> 1) Both of the Unix media servers do not have a NET_BUFFER_SZ file defined.
> So they should default to 32032. But they don't. Both media servers flip
> between 32120 and 33120. The bptm logs show that they attempt to use 32032,
> but Solaris 8 (or something) is telling them to use 32120 or 33120, and then
> at random points later in the day they flip to the other size. Can anyone
> figure this out?
>
> I've checked xmit_hiwat (16384) and recv_hiwat (24???) and
> max_tcp_buffer_size (1MB)
>
>
> 2) Why would a Windows client buffer size have any baring on a media servers
> receive buffer size?
>
>
> Thanks,
> Dave.
>
>
> "ps" wrote in message
> news:C0E64381.146C0%fsck@smicker.com...
>> in article 44c09e15@ROSASTDMZ05., D R at a@b.c.d wrote on 7/21/06 12:53
>> AM:
>> It's either one per client or stream. If you're seeing a value other than
>> the default of 32032 then check your media server's setting at
>> /usr/openv/netbackup/NET_BUFFER_SZ or your windows client's setting in
>> registry key 'Buffer_Size' and unix client's setting at
>> /usr/openv/netbackup/NET_BUFFER_SZ.
>>
>
>
That is odd about number one, I don't have an answer for that. Client values
override the media server's, which would explain #2.
--Paul