Veritas-bu

[Veritas-bu] NUMBER_ & SIZE_DATA BUFFERS

2000-12-19 10:31:20
Subject: [Veritas-bu] NUMBER_ & SIZE_DATA BUFFERS
From: David A. Chapa david AT datastaff DOT com
Date: Tue, 19 Dec 2000 09:31:20 -0600
Rick:

Its hard to say without seeing more of the log.  From this it doesn't look
like there is much of a problem except for the fact that you are seeing slow
backup times for this client.

Does this client's class go to a specific storage unit?

David

-----Original Message-----
From: Keahey, Ricky L [mailto:ricky.l.keahey AT intel DOT com]
Sent: Monday, December 18, 2000 6:21 PM
To: 'David A. Chapa'; Jim VandeVegt
Cc: NetBackup Veritas
Subject: RE: [Veritas-bu] NUMBER_ & SIZE_DATA BUFFERS


Ok, since we are on this subject, I have been having some slow backups on
one of my NT clients.  Below is what I got from my bptm log.  Any
suggestions on what I need to increase/decrease here?  This is a large store
with over 1 million small files.  And yes it is a web server running IIS.
Thanks in advance for any suggestons.

18:39:12 [544.543] <2> write_data: writing block shorter than BUFF_SIZE,
2048 bytes
18:39:12 [544.543] <2> write_data: writing short block, 2048 bytes,
remainder 0
18:39:13 [544.543] <2> write_data: waited for full buffer 361 times, delayed
2909 times

Thanks,
Rick

-----Original Message-----
From: David A. Chapa [mailto:david AT datastaff DOT com]
Sent: Monday, December 18, 2000 10:30 AM
To: Jim VandeVegt
Cc: NetBackup Veritas
Subject: Re: [Veritas-bu] NUMBER_ & SIZE_DATA BUFFERS


Jim:

Before I would change the NUMBER and SIZE, I would
create a bptm logging directory.

/usr/openv/netbackup/logs/bptm

this should be created on each of your media servers
(including any master that has netbackup controlled
devices).

this log will let you know how your buffer situation
looks.

For one of my clients, I have found that the defaults
were just about fine, with a slightly different
orientation.

instead of the 8x64 I tried 16x32 (most of the backups
use multiplexing).  This increased the speed quite a
bit and using the bptm logging directory you are able
to measure those results accordingly.

My 2 cents.

David Chapa

Quoting Jim VandeVegt <vandevegt AT yahoo DOT com>:

> Can other readers share what your NUMBER and
SIZE_DATA_BUFFERS are in
> /usr/openv/netbackup/db/config?
>
> My master server is a Sun 450, 1 GB RAM, 2x 400 MHz
processing.
> Shared Memory MAX is set to 1GB in /etc/system. Six
tape drives.
>
> I recently noticed my backups were going pretty slow
and I realized I
> didn't have these two files in place, thus I was
using the default
> 8x32KB buffers. I remembered from my NetBackup class
that almost
> everyone increases the size of the buffers and
usually decreases the
> numbers, but maintains a great increase in the total
size of the
> buffer (size times number).
>
> I tried 4 buffers 1048576 bytes (2^20 = 1 MB) big. I
noticed a
> speedup in backups, but some NT clients started
throwing errors.
>
> Most of the errors are 174, a media manager error,
which doesn't make
> a lot of sense; and a few error 41 (network
connection timeout).
>
> But I haven't fully diagnosed the errors net in the
log files. I'm
> more interested in what other installations use for
the buffer settings.
>
> =====
> Jim VandeVegt
> vandevegt AT yahoo DOT com vandevegt AT avaya DOT com
> http://members.xoom.com/vandevegt
> Toilet paper should come off the front!
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
Products.
> http://shopping.yahoo.com/
> _______________________________________________
> 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
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu





<Prev in Thread] Current Thread [Next in Thread>