mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: maryedie@osdl.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: DBT3-pgsql large performance improvement 2.6.6-rc1
Date: Fri, 16 Apr 2004 14:49:43 -0700	[thread overview]
Message-ID: <20040416144943.3fc5744a.akpm@osdl.org> (raw)
In-Reply-To: <1082134307.16437.461.camel@localhost>

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.

> 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.


  reply	other threads:[~2004-04-16 21:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-16 16:51 Mary Edie Meredith
2004-04-16 21:49 ` Andrew Morton [this message]
2004-04-19 23:14 Mary Edie Meredith
2004-04-29 23:50 ` Mary Edie Meredith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040416144943.3fc5744a.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maryedie@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome