All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mary Edie Meredith <maryedie@osdl.org>
To: linux-mm@kvack.org
Cc: Mary Edie Meredith <maryedie@osdl.org>
Subject: Poor DBT-3 pgsql 8way numbers on recent 2.6 mm kernels
Date: Fri, 12 Mar 2004 14:31:25 -0800	[thread overview]
Message-ID: <1079130684.2961.134.camel@localhost> (raw)

For the last few mm kernels, I have discovered a
performance problem in DBT-3 (using PostgreSQL) 
in the "throughput" portion of the test (when the
test is running multiple processes ) on our 8-way
STP systems as compared to 4-way runs and the baseline
kernel results.

Using the default DBT-3 options (ie using LVM, ext2, 
PostgreSQL version 7.4.1) on RH9 for 2.6.4-mm1 (PLM 2745)
[Note that the 4-way number is _better than the 8-way 
number]

2.6.4-mm1
Runid..CPUs.Thruput (bigger is better) 
289860 8    86.5<-----------(profiling data below)
289831 4    112.7
 
Compare to base:  
linux-2.6.4
Runid..CPUs.Thruput 
289421 8    137.2<----------
289383 4    120.73

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 and it almost completely 
caches in page cache early on. So there is not a lot 
of physical IO in the throughput portion of the test. 

I also found similar 8way thruput numbers on these 
mm kernels:

Kernel........PLM..Thruput 
2.6.4rc2-mm1  2676  84.56
2.6.4rc1-mm2  2666  85.54
2.6.4rc1-mm1  2664  85.73


Before the 2.6.3-mm4 kernel, the test we are running
now (with LVM and pgsql 7.4.1 was not available) so 
results are not availablewithout running them manually.  
I did run 2.6.1-mm5and it had a thruput result of 124.02 
on an 8way. Still not great but definitely better 
than ~86.0.

I just wanted to report this and I wonder if you already
know why this is happening.


--------------------------------------------------
Profiling data from RUNID 289860 sorted first by 
ticks, second by load:
http://khack.osdl.org/stp/289860/profile/Framework_Close-tick.sort
http://khack.osdl.org/stp/289860/profile/Framework_Close-load.sort
-- 
Mary Edie Meredith 
maryedie@osdl.org
503-626-2455 x42
Open Source Development Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

             reply	other threads:[~2004-03-12 22:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 22:31 Mary Edie Meredith [this message]
2004-03-13  7:39 ` Poor DBT-3 pgsql 8way numbers on recent 2.6 mm kernels Andrew Morton
     [not found]   ` <405379ED.A7D6B1E4@us.ibm.com>
2004-03-13 21:48     ` Andrew Morton
2004-03-15 16:45       ` Mary Edie Meredith
2004-03-15 17:16         ` Badari Pulavarty
2004-03-15 19:33         ` Ram Pai
2004-03-17 19:31           ` Mary Edie Meredith
2004-03-17 20:33             ` Ram Pai

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=1079130684.2961.134.camel@localhost \
    --to=maryedie@osdl.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.