Reducing onload time
We have a few test databases that we refresh periodically using
onunload/onload. The onload generally takes a very long time. For example,
re-creating an 8Gb database takes approximately 8 hours! Below are the details
Onload command: "onload -t /dumpdir/dbfile -b 64 -s 10000000 -d tabldbs testDB"
In an attempt to reduce the load times I have changed the following:
Changed PHYSFILE: 1000 => 20000
Changed CKPTINTVL: 900 => 3600
Changed NUMAIOVPS: 2 => 8
Changed BUFFERS: 20000 => 200000
Changed LRUS: 8 => 60
Changed LRU_MAX_DIRTY: 8 => 80
Changed LRU_MIN_DIRTY: 4 => 70
Changed RA_PAGES: => 32
Changed RA_THRESHOLD: => 16
The above changes reduced the load time from about 12 hours to 8 hours but I
think 8 hours is still excessive for a reasonably small DB.
The main issue seems to be that during the load the engine is checkpointing
excessively. Below is an extract of the online log: -
12:30:04 Maximum server connections 2
12:31:45 Fuzzy Checkpoint Completed: duration was 28 seconds, 13 buffers not
flushed.
12:31:45 Checkpoint loguniq 873, logpos 0xb090dc, timestamp: 0x169800d8
12:31:45 Maximum server connections 2
12:33:22 Fuzzy Checkpoint Completed: duration was 31 seconds, 13 buffers not
flushed.
12:33:22 Checkpoint loguniq 873, logpos 0xb0a0dc, timestamp: 0x1698726f
12:33:22 Maximum server connections 2
12:35:05 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffers not
flushed.
12:35:05 Checkpoint loguniq 873, logpos 0xb0b0dc, timestamp: 0x1698e403
12:35:05 Maximum server connections 2
12:36:36 Fuzzy Checkpoint Completed: duration was 33 seconds, 13 buffers not
flushed.
12:36:36 Checkpoint loguniq 873, logpos 0xb0c0dc, timestamp: 0x1699559a
12:36:36 Maximum server connections 2
12:37:52 Fuzzy Checkpoint Completed: duration was 23 seconds, 13 buffers not
flushed.
12:37:52 Checkpoint loguniq 873, logpos 0xb0d0dc, timestamp: 0x1699c72e
12:37:52 Maximum server connections 2
12:39:23 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffers not
flushed.
12:39:23 Checkpoint loguniq 873, logpos 0xb0e0dc, timestamp: 0x169a38c5
12:39:23 Maximum server connections 2
12:40:49 Fuzzy Checkpoint Completed: duration was 34 seconds, 13 buffers not
flushed.
12:40:49 Checkpoint loguniq 873, logpos 0xb0f0dc, timestamp: 0x169aaa59
12:40:49 Maximum server connections 2
12:42:13 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffers not
flushed.
12:42:13 Checkpoint loguniq 873, logpos 0xb100dc, timestamp: 0x169b1bf0
Any ideas on how to improve this load performance?
Thanks
Paul Ridding
1) AIO will help when you use cooked file.
2) use "onpload (High Performance Loader)" may help a lot of work
3) if table is large, try fragmentation
-----Original Message-----
From: "PAUL RIDDING" <pridding@tt.com.au>
To: ids@iiug.org
Date: Mon, 24 Sep 2007 20:29:00 -0400 (EDT)
Subject: Reducing onload time [9993]
> We have a few test databases that we refresh periodically using
> onunload/onload. The onload generally takes a very long time. For
> example,
> re-creating an 8Gb database takes approximately 8 hours! Below are the
> details
>
> Onload command: "onload -t /dumpdir/dbfile -b 64 -s 10000000 -d tabldbs
> testDB"
>
> In an attempt to reduce the load times I have changed the following:
>
> Changed PHYSFILE: 1000 => 20000
> Changed CKPTINTVL: 900 => 3600
> Changed NUMAIOVPS: 2 => 8
> Changed BUFFERS: 20000 => 200000
> Changed LRUS: 8 => 60
> Changed LRU_MAX_DIRTY: 8 => 80
> Changed LRU_MIN_DIRTY: 4 => 70
> Changed RA_PAGES: => 32
> Changed RA_THRESHOLD: => 16
>
> The above changes reduced the load time from about 12 hours to 8 hours
> but I
> think 8 hours is still excessive for a reasonably small DB.
>
> The main issue seems to be that during the load the engine is
> checkpointing
> excessively. Below is an extract of the online log: -
>
> 12:30:04 Maximum server connections 2
> 12:31:45 Fuzzy Checkpoint Completed: duration was 28 seconds, 13
> buffers not
> flushed.
> 12:31:45 Checkpoint loguniq 873, logpos 0xb090dc, timestamp: 0x169800d8
>
> 12:31:45 Maximum server connections 2
> 12:33:22 Fuzzy Checkpoint Completed: duration was 31 seconds, 13
> buffers not
> flushed.
> 12:33:22 Checkpoint loguniq 873, logpos 0xb0a0dc, timestamp: 0x1698726f
>
> 12:33:22 Maximum server connections 2
> 12:35:05 Fuzzy Checkpoint Completed: duration was 32 seconds, 13
> buffers not
> flushed.
> 12:35:05 Checkpoint loguniq 873, logpos 0xb0b0dc, timestamp: 0x1698e403
>
> 12:35:05 Maximum server connections 2
> 12:36:36 Fuzzy Checkpoint Completed: duration was 33 seconds, 13
> buffers not
> flushed.
> 12:36:36 Checkpoint loguniq 873, logpos 0xb0c0dc, timestamp: 0x1699559a
>
> 12:36:36 Maximum server connections 2
> 12:37:52 Fuzzy Checkpoint Completed: duration was 23 seconds, 13
> buffers not
> flushed.
> 12:37:52 Checkpoint loguniq 873, logpos 0xb0d0dc, timestamp: 0x1699c72e
>
> 12:37:52 Maximum server connections 2
> 12:39:23 Fuzzy Checkpoint Completed: duration was 32 seconds, 13
> buffers not
> flushed.
> 12:39:23 Checkpoint loguniq 873, logpos 0xb0e0dc, timestamp: 0x169a38c5
>
> 12:39:23 Maximum server connections 2
> 12:40:49 Fuzzy Checkpoint Completed: duration was 34 seconds, 13
> buffers not
> flushed.
> 12:40:49 Checkpoint loguniq 873, logpos 0xb0f0dc, timestamp: 0x169aaa59
>
> 12:40:49 Maximum server connections 2
> 12:42:13 Fuzzy Checkpoint Completed: duration was 32 seconds, 13
> buffers not
> flushed.
> 12:42:13 Checkpoint loguniq 873, logpos 0xb100dc, timestamp: 0x169b1bf0
>
> Any ideas on how to improve this load performance?
> Thanks
>
> Paul Ridding
>
>
> ***********************************************************************
> ********
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Just a guess, but you can improve your performance by increasing your
physical log size. Also
check the physical log buffer size. The checkpoints need to take plac=
e
when the physical log
is 75% full so it starts at 15MB. A majority of the 8Gb you load will=
be
sent through the physical log.
The only other trick I might have for you is to load the onload into a =
new
dbspace. If you
are reusing a previous allocated piece of disk make sure it does not ha=
ve
the same informix
page address (i.e. change the starting offset by 1 page).
When putting a page in the physical log, if the page does not have a va=
lid
Informix
page address then we avoid putting this page into the physical log. Th=
is
would be
true of a new dbspace. This way you could avoid all the checkpoints !=
!!
John
=
"PAUL RIDDING" =
<pridding@tt.com. =
au> =
To
Sent by: ids@iiug.org =
ids-bounces@iiug. =
cc
org =
Subj=
ect
Reducing onload time [9993] =
09/24/2007 05:29 =
PM =
=
=
Please respond to =
ids@iiug.org =
=
=
We have a few test databases that we refresh periodically using
onunload/onload. The onload generally takes a very long time. For examp=
le,
re-creating an 8Gb database takes approximately 8 hours! Below are the
details
Onload command: "onload -t /dumpdir/dbfile -b 64 -s 10000000 -d tabldbs=
testDB"
In an attempt to reduce the load times I have changed the following:
Changed PHYSFILE: 1000 =3D> 20000
Changed CKPTINTVL: 900 =3D> 3600
Changed NUMAIOVPS: 2 =3D> 8
Changed BUFFERS: 20000 =3D> 200000
Changed LRUS: 8 =3D> 60
Changed LRU_MAX_DIRTY: 8 =3D> 80
Changed LRU_MIN_DIRTY: 4 =3D> 70
Changed RA_PAGES: =3D> 32
Changed RA_THRESHOLD: =3D> 16
The above changes reduced the load time from about 12 hours to 8 hours =
but
I
think 8 hours is still excessive for a reasonably small DB.
The main issue seems to be that during the load the engine is checkpoin=
ting
excessively. Below is an extract of the online log: -
12:30:04 Maximum server connections 2
12:31:45 Fuzzy Checkpoint Completed: duration was 28 seconds, 13 buffer=
s
not
flushed.
12:31:45 Checkpoint loguniq 873, logpos 0xb090dc, timestamp: 0x169800d8=
12:31:45 Maximum server connections 2
12:33:22 Fuzzy Checkpoint Completed: duration was 31 seconds, 13 buffer=
s
not
flushed.
12:33:22 Checkpoint loguniq 873, logpos 0xb0a0dc, timestamp: 0x1698726f=
12:33:22 Maximum server connections 2
12:35:05 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffer=
s
not
flushed.
12:35:05 Checkpoint loguniq 873, logpos 0xb0b0dc, timestamp: 0x1698e403=
12:35:05 Maximum server connections 2
12:36:36 Fuzzy Checkpoint Completed: duration was 33 seconds, 13 buffer=
s
not
flushed.
12:36:36 Checkpoint loguniq 873, logpos 0xb0c0dc, timestamp: 0x1699559a=
12:36:36 Maximum server connections 2
12:37:52 Fuzzy Checkpoint Completed: duration was 23 seconds, 13 buffer=
s
not
flushed.
12:37:52 Checkpoint loguniq 873, logpos 0xb0d0dc, timestamp: 0x1699c72e=
12:37:52 Maximum server connections 2
12:39:23 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffer=
s
not
flushed.
12:39:23 Checkpoint loguniq 873, logpos 0xb0e0dc, timestamp: 0x169a38c5=
12:39:23 Maximum server connections 2
12:40:49 Fuzzy Checkpoint Completed: duration was 34 seconds, 13 buffer=
s
not
flushed.
12:40:49 Checkpoint loguniq 873, logpos 0xb0f0dc, timestamp: 0x169aaa59=
12:40:49 Maximum server connections 2
12:42:13 Fuzzy Checkpoint Completed: duration was 32 seconds, 13 buffer=
s
not
flushed.
12:42:13 Checkpoint loguniq 873, logpos 0xb100dc, timestamp: 0x169b1bf0=
Any ideas on how to improve this load performance?
Thanks
Paul Ridding
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Hi,
hardware data would be helpful (at least number of CPUs, available RAM, OS,
disksystem
with/without cache) - load times depend on hardware :-)
If your are running without KAIO (kernel asynchronous I/O) you might increase
NUMAIOVPSfurther (check with onstat -g iov - as long as io/wup shows values > 1 for all
AIO-vps you should increase NUMAIOVPS). Too many NUMAIOVPS don't hurt unless
you are
running on a very very small machine.
A bigger PHYSFILE would help too - it reduces the number of checkpoints
necessary.
Is NUMCPUVPS appropriate for the machine?
Check with onstat -F if you see Fg (Foreground) Writes - if yes, you MUST
increase
BUFFERS. If you have the memory available increasing BUFFERS will never hurt.
Regards,
Andreas Kutsche
>
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
-----Ursprüngliche Nachricht-----
> Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]Im Auftrag von
> PAUL RIDDING
> Gesendet: Dienstag, 25. September 2007 02:29
> An: ids@iiug.org
> Betreff: Reducing onload time [9993]
>
>
> We have a few test databases that we refresh periodically using
> onunload/onload. The onload generally takes a very long time.
> For example,
> re-creating an 8Gb database takes approximately 8 hours!
> Below are the details
>
> Onload command: "onload -t /dumpdir/dbfile -b 64 -s 10000000
> -d tabldbs
> testDB"
>
> In an attempt to reduce the load times I have changed the following:
>
> Changed PHYSFILE: 1000 => 20000
> Changed CKPTINTVL: 900 => 3600
> Changed NUMAIOVPS: 2 => 8
> Changed BUFFERS: 20000 => 200000
> Changed LRUS: 8 => 60
> Changed LRU_MAX_DIRTY: 8 => 80
> Changed LRU_MIN_DIRTY: 4 => 70
> Changed RA_PAGES: => 32
> Changed RA_THRESHOLD: => 16
>
> The above changes reduced the load time from about 12 hours
> to 8 hours but I
> think 8 hours is still excessive for a reasonably small DB.
>
> The main issue seems to be that during the load the engine is
> checkpointing
> excessively. Below is an extract of the online log: -
>
> 12:30:04 Maximum server connections 2
> 12:31:45 Fuzzy Checkpoint Completed: duration was 28 seconds,
> 13 buffers not
> flushed.
> 12:31:45 Checkpoint loguniq 873, logpos 0xb090dc, timestamp:
> 0x169800d8
>
> 12:31:45 Maximum server connections 2
> 12:33:22 Fuzzy Checkpoint Completed: duration was 31 seconds,
> 13 buffers not
> flushed.
> 12:33:22 Checkpoint loguniq 873, logpos 0xb0a0dc, timestamp:
> 0x1698726f
>
> 12:33:22 Maximum server connections 2
> 12:35:05 Fuzzy Checkpoint Completed: duration was 32 seconds,
> 13 buffers not
> flushed.
> 12:35:05 Checkpoint loguniq 873, logpos 0xb0b0dc, timestamp:
> 0x1698e403
>
> 12:35:05 Maximum server connections 2
> 12:36:36 Fuzzy Checkpoint Completed: duration was 33 seconds,
> 13 buffers not
> flushed.
> 12:36:36 Checkpoint loguniq 873, logpos 0xb0c0dc, timestamp:
> 0x1699559a
>
> 12:36:36 Maximum server connections 2
> 12:37:52 Fuzzy Checkpoint Completed: duration was 23 seconds,
> 13 buffers not
> flushed.
> 12:37:52 Checkpoint loguniq 873, logpos 0xb0d0dc, timestamp:
> 0x1699c72e
>
> 12:37:52 Maximum server connections 2
> 12:39:23 Fuzzy Checkpoint Completed: duration was 32 seconds,
> 13 buffers not
> flushed.
> 12:39:23 Checkpoint loguniq 873, logpos 0xb0e0dc, timestamp:
> 0x169a38c5
>
> 12:39:23 Maximum server connections 2
> 12:40:49 Fuzzy Checkpoint Completed: duration was 34 seconds,
> 13 buffers not
> flushed.
> 12:40:49 Checkpoint loguniq 873, logpos 0xb0f0dc, timestamp:
> 0x169aaa59
>
> 12:40:49 Maximum server connections 2
> 12:42:13 Fuzzy Checkpoint Completed: duration was 32 seconds,
> 13 buffers not
> flushed.
> 12:42:13 Checkpoint loguniq 873, logpos 0xb100dc, timestamp:
> 0x169b1bf0
>
> Any ideas on how to improve this load performance?
> Thanks
>
> Paul Ridding
>
>
> **************************************************************
> *****************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>