Sure, I've seen the same thing. There are many
variables, but let me build a scenario for example.
ClassA, MPX=4 on Incr MPX=1 on Full, 30 PCNT Clients
ClassB, MPX=1 on both types, 60 Unix clients
STUNIT=4DRV-DLT7000
NETWORK=100BT - SWITCHED
MPX=8
When I look at my bptm log, I'll more than likely see
a mixture of waits for full and empty. Depending on
what stream is indicating the full or empty will
determine how I go about addressing my performance
tuning.
I may see that the NT backup is waiting for full buffer
quite a lot, while the Unix is waiting for empty...what
I would probably do is to address the waiting for full
by increasing the MPX value in my class first (assuming
in this example that the backups on the INCRM
schedules). Then see if that clears up the significant
wait for full buffer. After tweaking this, then I
would address the waiting for empty by increasing the
number of buffers, not necessarily the size.
Now this may not give you what you are looking for at
all, let's say these changes didn't improve your
performance whatsoever. Another thing I have done with
great success is to increase the number of buffers and
decrease the size. In other words, in most of the
environments that I have consulted in the NT backups
have always been the slowest, therefore INCR schedules
would be MPX (8x64), so changing the num=16 and size=32
helped increase the performance quite a bit.
another thing that I have seen quite frankly is a
simple network fix, the NT machines were not 100/FULL
by default, but AUTO, which doesn't always negotiate at
100/FULL. Similarly, Solaris boxes are notorious for
not play well with the AUTO set on their NIC either, so
making sure that they are set to 100/FULL (for my
example) would be another avenue to test.
I don't mean to get basic on you or insult your
intelligence with regard to answering your question,
but it does go along with the whole process of tuning.
I hope this helps.
David
Your mileage may vary
<><><><><><><><><><><><><><><><><><><><>
David A. Chapa
Consulting Manager
DataStaff, Inc.
847 413 1144
http://www.consulting.datastaff.com
---------------------------------------
NBU-LSERV AT datastaff DOT com - Adv. Scripting
Quoting "Zufall, Ken" <KZufall AT officemax DOT com>:
> David,
>
> Good information here, but what if you're seeing a
mixture of waits on
> empty
> and full buffers? My numbers seem to be spread
pretty evenly, though I do
> get slightly more waits for empty buffers on a daily
basis...
>
> Ken Zufall
> Technical Analyst
> Phone: 216.471.3613
> Pager: 440.303.1656
> Fax: 216.491.4051
>
> "It's not the most intellectual job, but I do have to
know all the
> letters."
> Vanna White
>
>
>
> -----Original Message-----
> From: David A. Chapa
[mailto:david AT datastaff DOT com]
> Sent: Tuesday, February 20, 2001
11:13 AM
> To: Caddell, Scott; veritas-
bu AT mailman.eng.auburn DOT edu
> Cc: Nbu-Lserv@Datastaff. Com
> Subject: [Veritas-bu] RE:
[NBUADV-L]: Performance
> Tuning
> Sensitivity: Confidential
>
> Scott:
>
> I've never created the keys, but what I
have done (on NT) is
> to create the
> files NUMBER_DATA_BUFFERS and
SIZE_DATA_BUFFERS in
> /veritas/netbackup/db/config, which
works just as well.
>
> As far as guidelines goes, I would
first create a bptm log
> and begin
> monitoring the performance of your
media servers (these
> buffer files will
> only need to be created on the MEDIA
SERVERS).
>
> Based on the information you gleen from
there, I would make
> my changes from
> default (8x32 - 8 DATA BUFFERS x 32K ea
for non multiplex
> and 8x64 for
> multiplex).
>
> My own experience has been that I have
seen increased
> performance when I
> decrease the number of buffers and
increase the size, but
> your mileage may
> vary depending on your own environment.
>
> What to look for in the bptm logs?
>
> waited for full buffer
>
> this is the number of times bptm had to
wait for a full
> buffer. This would
> indicate less data coming from the
network, so adding more
> buffers will not
> help, but perhaps reducing the number
of buffers *MIGHT*.
>
> waited for empty buffer
>
> how many times bptm had to wait for the
buffer to empty.
> This would
> indicate more data coming from the
network than the drive
> can handle so more
> buffers would apply here.
>
> The delayed xxxxx times in the logs
message
>
> is the number of time bptm waited in
the loop for an
> available buffer (30ms
> delay ea. time)
>
>
> Hope this helps.
>
> David
>
>
>
> <><><><><><><><><><><><><><><><><><><><>
> David A. Chapa
> Consulting Manager
> DataStaff, Inc.
> 847 413 1144
> http://www.consulting.datastaff.com
> ---------------------------------------
> NBU-LSERV AT datastaff DOT com - Adv. Scripting
>
> -----Original Message-----
> From: owner-nbu-lserv AT datastaff DOT com
> [mailto:owner-nbu-lserv AT datastaff DOT com]
On Behalf Of Caddell,
> Scott
> Sent: Tuesday, February 20, 2001 9:44 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Cc: Nbu-Lserv@Datastaff. Com
> Subject: [NBUADV-L]: Performance Tuning
> Sensitivity: Confidential
>
>
> I need to do some SCSI performance
tuning on my W2K Master
> (3.4). I am
> pretty
> sure I need to create some registry
keys in
> HKLM/Software/Veritas/config
> called
> Number_Data_Buffers and
Size_Data_Buffers, but I'm not sure
> on how I should
> set
> the values. Does anyone have
information on creating these
> keys and a
> guideline
> on tuning?
>
> Thanks,
>
> Scott Caddell
> Intersil Corporation
> Palm Bay, FL
> ----------------------------------------
---------------
> NBU-LSERV AT datastaff DOT com - Advanced
NetBackup Scripting
>
http://www.consulting.datastaff.com/adv_script_s
ite
>
>
>
_______________________________________________
> Veritas-bu maillist - Veritas-
bu AT mailman.eng.auburn DOT edu
>
http://mailman.eng.auburn.edu/mailman/listinfo/v
eritas-bu
> _______________________________________________
> Veritas-bu maillist - Veritas-
bu AT mailman.eng.auburn DOT edu
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
bu
>
<><><><><><><><><><><><><><><><><><><><>
David A. Chapa
Consulting Manager
DataStaff, Inc.
847 413 1144
http://www.consulting.datastaff.com
---------------------------------------
NBU-LSERV AT datastaff DOT com - Adv. Scripting
|
