Re: IDS 7.30 on Linux Tuning Benchmark?
Posted in 1999
Topics: Performance & Tuning, Storage & Space Management, Platform-Specific Issues, Versions, Editions & End-of-Life
From: Tim Schaefer <tschaefe@mindspring.com> > >I applied the "Kagel Krank" to the LRU's: LRUMAX 2 LRUMIN 1 For a load, I would rather set LRUMAX and MIN to high values, and only do a chunk write once all the data was in. This might require more buffers. But that's just me. :-) HTH. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
OK Clownster,
I went from 2 and 1 to 98 and 1, did an onmode -c after each 10,000 rows.
Nothing else changed in the onconfig, my buffers stayed the same, at 25%
of Virtual Memory per the book. So...
This gave me 2-second checkpoints, no FG's and all Chunk Writes:120135
No LRU writes. Very nice loading. I reduced the loading from 7:51 to 6:44,
( min:sec ) to now give me 1666 records/sec. This was interrupted though
by the two-second checkpoints.
I also tried taking out the onmode -c after each 10,000 row load, and doubled
the buffers, but this caused long checkpoints averaging around 6 or 7 seconds.
It did reduce the total load time further to 5:04. Very interesting, because
the loads went like this:
:06
:06
:14 < ckpt
:06
:06
:05
:14 < ckpt
Interesting, even at that it was a faster load. I guess this is the way
to go for now.
I've also loaded a 97,029 row loadfile in 17 seconds this way, with a 2-sec
checkpoint. 5707 recs/sec. Very interesting. Also, if I load a series
of these loadfiles, I get all chunk writes, no LRU writes, and checkpoints
exactly even at 4 secs, with a 13 second average load time. ( 7463.76 recs/sec )
Hmmmmm... Linux ain't so bad I guess, but I really don't have a reference point
other than XPS lately.
It would be better to get a high-performance loader ported, so we could
avoid the buffer problem altogether. This would eliminate having to chop up
load files. Unless of course I'm missing something, I can't load large loads
without incurring long transactions.
BTW, Somebody implied lately that you went from vaudeville to the big top.
Any truth to that? 8-)
Obnoxio The Clown wrote:
>
> From: Tim Schaefer <tschaefe@mindspring.com>
> >
> >I applied the "Kagel Krank" to the LRU's: LRUMAX 2 LRUMIN 1
>
> For a load, I would rather set LRUMAX and MIN to high values, and only do a
> chunk write once all the data was in. This might require more buffers. But
> that's just me. :-)
>
> HTH.
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
--
-
--
--- Tim Schaefer
---- tschaefe@mindspring.com
--- http://www.inxutil.com
--
-
Tim Schaefer wrote:
[benchmark SNIPPED]
> It would be better to get a high-performance loader ported, so we could
> avoid the buffer problem altogether. This would eliminate having to chop up
> load files. Unless of course I'm missing something, I can't load large loads
> without incurring long transactions.
How about dbload with the partial commit flag? Or my ul.ec binary file
loader/unloader which also performs commits every N rows?
Art S. Kagel
"Art S. Kagel" wrote:
>
> Tim Schaefer wrote:
> [benchmark SNIPPED]
> > It would be better to get a high-performance loader ported, so we could
> > avoid the buffer problem altogether. This would eliminate having to chop up
> > load files. Unless of course I'm missing something, I can't load large loads
> > without incurring long transactions.
>
> How about dbload with the partial commit flag? Or my ul.ec binary file
> loader/unloader which also performs commits every N rows?
>
> Art S. Kagel
I'm interested in your EC program, will investigate shortly...
Tim
--
-
--
--- Tim Schaefer
---- tschaefe@mindspring.com
--- http://www.inxutil.com
--
-