lkml.org 
[lkml]   [2004]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: DBT3-pgsql large performance improvement 2.6.6-rc1
Date
Mary Edie Meredith wrote:
.snip
>
>>Mary Edie Meredith <maryedie@osdl.org> wrote:
>>
>>>Performance in DBT-3 (using PostgreSQL) has vastly
>>>improved for _both in the "power" portion (single
>>>process/query) and in the "throughput" portion of
>>>the test (when the test is running multiple processes)
>>>on our 4-way(4GB) and 8-way(8GB) STP systems as
>>>compared 2.6.5 kernel results.
>>>
>>>Using the default DBT-3 options (ie using LVM, ext2,
>>>PostgreSQL version 7.4.1)
>>>
>>>Note: Bigger numbers are better.
>>>
>>>Kernel....Runid..CPUs.Power..%incP.Thruput %incT
>>>2.6.5 291308 4 97.08 base 120.46 base
>>>2.6.6-rc1 291876 4 146.11 50.5% 222.94 85.1%
>>>
>>>Kernel....Runid..CPUs.Power..%incP..Thruput %incT
>>>2.6.5 291346 8 101.08 base 138.95 base
>>>2.6.6-rc1 291915 8 151.69 50.1% 273.69 97.0%
>>>
>>>So the improvement is between 50% and 97%!
>>
>>How odd.

Your instincts were right (as usual).

We took another closer look at this. It appears that
a change slipped into the kit around April 13, which
probably made this stunning performance difference
not the kernel.

Results of second run of the linux-2.6.5 kernel using the
changed test kit showed that the numbers are comparable
to the latest 2.6.6-rc3 release. Therefore,
it looks like the initial improvements posted were
most likely due to the change in datatypes
making the database size smaller, among other things.

....................Composite....Power...Throughput


initial linux 2.6.5 108.14 97.08 120.46
second linux 2.6.5 180.62 146.53 222.63
linux 2.6.6-rc3 181.83 147.16 224.68

Tests were compared on 4-way systems. (Bigger is better).

We will run the 8-way numbers over night to see if there is
any difference for those systems. We are also running some
IA64 results over night as well.


>>
>>
>>>Profile 2.6.5 8way throughput phase:
>>>http://khack.osdl.org/stp/291346/profile/after_throughput_test_1-tick.sort
>>>Profile 2.6.6-r1 8way throughput phase:
>>>http://khack.osdl.org/stp/291915/profile/after_throughput_test_1-tick.sort
>>
>>Odder. do_anonymous_page() is doing 10x more work in 2.6.6-rc1. And the
>>CPU scheduler cost has fallen a lot.
>>
>>Frankly, I can't think of anything in 2.6.6-rc1 which would cause either of
>>these things!
>>
>>
>>>What I notice is that radix_tree_lookup is in
>>>the top 20 in the 2.6.5 profile, but not in
>>>2.6.6-rc1. Could theradix tree changes be
>>>responsible for this?
>>
>>I would certainly expect 2x or even higher throughput increases from either
>>the writeback changes or the ext2&ext3 fsync changes.
>>
>>
>>>DBT-3 is a read mostly DSS workload and the throughput
>>>phase is where we run multiple query streams (as
>>>many as we have CPUs). In this workload, the database
>>>is stored on a file system, but it is small relative
>>>to the amount of memory (4GB and 8GB). It almost
>>>completely caches in page cache early on. So there
>>>is some physical IO in the first few minutes, but very
>>>little to none in the remainder.
>>
>>But you're not doing a significant amount of writing during the test, so
>>scrub that theory.
>>
>>Do you have full reports anywhere? I'd be interested in seeing a vmstat
>>trace from the entire run, both 2.6.5 and 2.6.6-rc1.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.054 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site