ontape vs onbar

#11

Hi,

if you want to get to the bottom of this I think it is time to analyse,
where the bottleneck is. Ontape is rather simple, writing directly to
a (usually local) tape.

ON-Bar involves several components and you should look at each
of these and the communication between them. You can start with
the ON-Bar activity log file to check if there is a certain "phase" in
the backup that takes longer than expected. You can also
check/compare to the respective lines in IDS message log. You
may also want to look into ISM log files, but you may find that
messages there do not exactly (time-) match with messages from
ON-Bar.

If you find something suspicious, you may want to switch on some
tracing (e.g. BAR_DEBUG value to 2, 3 or 4) to get more timing info.
While this will slow down the operation as a whole, it should give
more info as to where the time (in relative values) is spent ...

This may by far not be the end of the line, but at least it should
give you an idea where to start.

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list (AT) iiug (DOT) org wrote on 16.08.2005 22:40:03:

Quote:

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> wrote in message
news:3m44k0F156p6lU1 (AT) individual (DOT) net...
"Sebastian, Norma J." <NormaJean.Sebastian (AT) tellabs (DOT) com> wrote in
message
news:1123819964.db90e50df91cec9c2fd9298509fcd802 (AT) teranews (DOT) ..
Neil Truby wrote:
IDS 10.0FC3 on Solaris 9
I'm doing some backups to disk.
An ontape backup of the 30G database with a 768k TAPEBLK takes
about
25
mins, but an onbar -b -L 0 takes over twice as long.
How many dbspaces?
Root, log log, phys log (3 x temp), one large application dbspace.
What is your storage manager?
ISM
How does onbar -b -w run?

Yes, onbar -w is even worse - about 2 hours, against 25 minutes with
ontape.
Very strange.

Anyway, I raised a call with Tech Support this morning (437443), so
we'll
see what they make of it.

Had the feedback through now. She says:

"Onbar compared to ontape incurs a greater overhead and therefore it is
likely to be slower than ontape. However the purpose of Onbar is to
provide
greater flexibility than ontape so this is the trade-off."

Then lots of general common sense about parallel backups which
unfortunately
can't be applied in this case where there is a single application
dbspace.

Well, I just supposed that a non-parallel onbar backup would deliver
equivalent performance to ontape, but it seems not to, and there doesn't

seem to be a workaround. The original question was based upon our
expectation that onbar in its non-parallel mode and ontape would deliver

broadly similar performance. I still don't feel I understand the answer
to
why this is not so: my unqualified hunch is that the answer lies in the
fact
that with ontape I was able to configure a very high "tape" block size
well
suited to a disk backup.

sending to informix-list

#12

"Martin Fuerderer" <MARTINFU (AT) de (DOT) ibm.com> wrote

Quote:

Hi,

if you want to get to the bottom of this I think it is time to analyse,
where the bottleneck is. Ontape is rather simple, writing directly to
a (usually local) tape.

ON-Bar involves several components and you should look at each
of these and the communication between them. You can start with
the ON-Bar activity log file to check if there is a certain "phase" in
the backup that takes longer than expected. You can also
check/compare to the respective lines in IDS message log. You
may also want to look into ISM log files, but you may find that
messages there do not exactly (time-) match with messages from
ON-Bar.

It just starts off slowly, and consistently writes out slowly, compared on
ontape. There's no particular phase in which it's slow, the throughput is
just consistently a quarter the speed on ontape's.

I should stress again here that both ontape and onbar are writing to *disk*
in this comparison.

If onbar is inherently slower, then it's slower. I'd just never noticed it
as being so before and am very surprised.

As I say. my hunch is still that it's all down to being able to configure
TAPEBLK in ontape, but not onbar ...

#13

Hi,

I/O block size for write operations indeed cannot be configured
in ON-Bar. This is mainly because ON-Bar doesn't do the I/O
write operations. The storage manager is doing them, therefore
you need to configure blocksize there.

With ISM as storage manager try the following:

- as user root execute "nsradmin"
- nsradmin> print NSR device
- nsradmin> update volume block size: 1024 KB
-- this will ask you several times (once for each device ?)
-- whether you want to update the value.
-- answer with "y" or "n" as appropriate ...
- nsradmin> quit
-- to leave nsradmin utility

All this is a bit cryptic, but it seems to work (at least it changes
the configured values for the device(s)).

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

owner-informix-list (AT) iiug (DOT) org wrote on 17.08.2005 15:11:51:

Quote:

"Martin Fuerderer" <MARTINFU (AT) de (DOT) ibm.com> wrote in message
news:1124275387.367f6e33d3f4593be9c8290f7a8a7071 (AT) teranews (DOT) ..

Hi,

if you want to get to the bottom of this I think it is time to
analyse,
where the bottleneck is. Ontape is rather simple, writing directly to
a (usually local) tape.

ON-Bar involves several components and you should look at each
of these and the communication between them. You can start with
the ON-Bar activity log file to check if there is a certain "phase" in
the backup that takes longer than expected. You can also
check/compare to the respective lines in IDS message log. You
may also want to look into ISM log files, but you may find that
messages there do not exactly (time-) match with messages from
ON-Bar.

It just starts off slowly, and consistently writes out slowly, compared
on
ontape. There's no particular phase in which it's slow, the throughput
is
just consistently a quarter the speed on ontape's.

I should stress again here that both ontape and onbar are writing to
*disk*
in this comparison.

If onbar is inherently slower, then it's slower. I'd just never noticed
it
as being so before and am very surprised.

As I say. my hunch is still that it's all down to being able to
configure
TAPEBLK in ontape, but not onbar ...

sending to informix-list

#14

What does ids_watch show whilst the backup is running. It should give
Mb/sec
or what ism is waiting for.

#15

What does ism_watch show whilst the backup is running?

It should give Mb/sec or what ism is waiting for.

#16

"Neil Truby" <neil.truby (AT) ardenta (DOT) com> schrieb:

Quote:

my unqualified hunch is that the answer lies in the fact
that with ontape I was able to configure a very high "tape" block size well
suited to a disk backup.

What block size is well suited for disk backup?

Do you have different block sizes configured for archives and logical log
backups? If so, what values?

Regards, Richard

#17

I did some short tests to backup 600MB data (1 dbspace) with onbar/ism and
ontape. Used onconfig.std except TAPEBLK 1024.

1. Debian Linux 3.1, 4 x Pentium3 900MHz, 4GB RAM:
time onbar -b -L 0
0.55user 6.27system 0:15.02elapsed 45%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8110minor)pagefaults 0swaps

time ontape.sh (echo | ontape -s -L 0)
0.16user 6.24system 0:24.77elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7817minor)pagefaults 0swaps

2. SuSE Linux 9.3, 1 x Pentium4 2GHz, 1GB RAM:
onbar -b -L 0
real 0m49.171s
user 0m1.026s
sys 0m1.945s

time ontape.sh (echo | ontape -s -L 0)
real 0m31.323s
user 0m0.112s
sys 0m2.765s

Obviously in my example onbar/ism performes better on the SMP machine:
15.02s to 24.77s with ontape. See also 45%CPU onbar to 25%CPU ontape. Onbar
CPU load was higher to complete earlier. The 'top' utility showed 1 oninit
and 1 nsrmmd (from ism) each on 1 CPU with 99% load.

Andreas

On Thursday 11 August 2005 23:02, Neil Truby wrote:

Quote:

IDS 10.0FC3 on Solaris 9

I'm doing some backups to disk.

An ontape backup of the 30G database with a 768k TAPEBLK takes about 25
mins, but an onbar -b -L 0 takes over twice as long.

I wonder if it's that the block size being used is much smaller? There's
some excellent documentation in the DB2 Information Center, but this
doesn;t seem to be configurable.

Also, it's writing out 15 x 2Gbyte files (sequentially) rather than one
large file: thought this would be different post-9.40. Anyone know why?

Thanks
Neil
sending to informix-list

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

ontape vs onbar

comp.databases.informix comp.databases.informix

Re: ontape vs onbar - 08-17-2005 , 04:10 AM

Re: ontape vs onbar - 08-17-2005 , 08:11 AM

Re: ontape vs onbar - 08-18-2005 , 05:03 AM

Re: ontape vs onbar - 08-18-2005 , 05:51 PM

Re: ontape vs onbar - 08-18-2005 , 05:52 PM

Re: ontape vs onbar - 08-19-2005 , 06:20 AM

Re: ontape vs onbar - 08-19-2005 , 09:37 AM