Porsuelo, Bryan writes:
> Hi,
> 
> What parameter should be adjusted given the following entries from bptm?

It's not possible to say, or even that any 'parameter' needs to be
adjusted at all.  The waits/delays give you an indication of how much
time was "wasted" at a very specific point in the data transfer
process.  From these numbers, you can get a feel for which side of
this point in the process you might start tuning with. 

> 
> 15:11:06 [165.212] <2> fill_buffer: [184] socket is closed, waited for empty
> buffer 24 times, delayed 377 times, read 14426080 Kbytes - Do I need to
> increase number_data_buffers here?

These values are very very small for 14 GB worth of data transfer.
This means that the bptm process in charge of accepting data was not
slowed down because the bptm process charged with sending that data to
tape couldn't keep up.

> 
> 15:11:14 [184.102] <4> write_backup: waited for full buffer 80491 times,
> delayed 80777 times - Do I need to increase size_data_buffers or
> NET_BUFFER_SZ for this?

These numbers are a bit high, maybe, it's hard to say without some
context.  You're looking at somewhere around 45 minutes worth of
time when the drive wasn't writing because it was waiting for more
input.  

This means that the process of getting the data off the disk, through
the filesystem, over the network, etc, is slower than the tape drive
can write.

> 
> I'm confused as to which among the three parameters I should modify.

Depends on what you're looking to accomplish.  If you're meeting your
current backup window, everyone's happy, etc, you probably have more
important things to do.  So what if your drive isn't busy - maybe it's
just really fast.

If you need to increase the performance of THIS backup, you need to
start looking at client disk and network.  The first thing I'd look at
is how many KB/s you got (because it's easy to compare against the
network limit).

If you've got many jobs and it's your OVERALL backup window you're
working on, and all of your drives are in use, you might try
multiplexing (so that drive has something to do while waiting for this
relatively slow client).  Then again, most people have a lot more
drive capacity than network capacity, so it may not matter anyway.

So, as we see these buffer readings provide a general direction, not a
direct answer.  You might try increasing the number of buffers at the
server in case the incoming traffic is rather bursty, but then that's
just one of a whole lot of things.

> 
> Thanks in advance,
> Bryan
> 
> 
> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-- 
Larry Kingery 
      Don't use a big word where a diminutive one will suffice.