mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Mansfield <lkml@dm.cobite.com>
To: Andrew Morton <akpm@digeo.com>, <linux-kernel@vger.kernel.org>
Subject: 2.5.59-mm7 results with database 'benchmark'
Date: Fri, 31 Jan 2003 16:54:10 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0301311641050.17695-100000@admin> (raw)


Hi Andrew et al.

I have run my 'production database load' against the 2.5.59-mm7 kernel.  
Fortunately for me, but unfortunately for you, I have upgraded the system 
CPUs.  They were 2 x PIII 866Mhz, 256kb cache, now 2 x PIII 1Ghz, 256kb 
cache.  I reran the 2.4.18-19.7.xsmp test as a baseline for comparison.  I 
include all results to date here.  System and workload descriptions 
follow. 

The (slight) advantage that the 2.5.59 series had over the RedHat
kernels has evaporated.  But it was marginal to begin with.

As usual, I'm willing to test...

Results:

kernel                        minutes
----------------------------- -----------
old cpus, 2x866mhz:
2.4.20-aa1                    134
2.5.59                        124
2.4.18-19.7.xsmp              128
2.5.59-mm5                    157
2.5.59-mm5-no-anticipatory-io 125
2.5.59-mm6                    125

new cpus, 2x1ghz:
2.4.18-19.7.xsmp              118  <---       new run
2.5.59-mm7                    118  <---       new run


Platform and configuration:
HP LH3000 U3.  Dual 1Ghz Intel Pentium III, 2GB ram.  megaraid controller
with two channels, each channel raid 5 (hardware raid) PV on 6 15k scsi
disks, one megaraid LV per PV.

Two plain disks w/pairs of partitions in raid 1 for OS (redhat 7.3), a
second pair of partitions (regular partitions with ext2) for Oracle 
redo-log (in a log 'group').

Oracle version 8.1.7.4 (no aio support in this release) is accessing
datafiles on the two megaraid devices via /dev/raw stacked on top of
device-mapper (lvm2).

Workload:
The workload consists of a few different phases.

1) Indexing: multiple indexes built against a 9 million row table.  This
is mostly about sequential scans of a single table, with bursts of write
activity.  50 minutes or so.

2) Analyzing: The database scans tables and
builds statistics.  Most of the time is spent analyzing the 9 million row
table.  This is a completely cpu bound step on our underpowered system.
30 minutes.

3) Summarization: the large table is aggregated in about 100
different ways.  Records are generated for each different summarization.
This is mixed read-write load.  50 minutes or so.

-- 
/==============================\
| David Mansfield              |
| lkml@dm.cobite.com           |
\==============================/



             reply	other threads:[~2003-01-31 21:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-31 21:54 David Mansfield [this message]
2003-01-31 22:18 ` Martin J. Bligh
2003-01-31 22:22 ` Andrew Morton
2003-02-14 22:14   ` [BENCHMARK] 2.5.60-mm2+anticipatory results with Oracle db load lkml

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=Pine.LNX.4.44.0301311641050.17695-100000@admin \
    --to=lkml@dm.cobite.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®