[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject2.5.59mm5 database 'benchmark' results

Hi Nick, Andrew, lists,

I've been testing some recent kernels to see how they compare with a
particular database workload. The workload is actually part of our
production process (last months run) but on a test server. I'll describe
the platform and the workload, but first, the results :-)

kernel minutes comment
------------- ----------- ---------------------------------
2.4.20-aa1 134 i consider this 'baseline'
2.5.59 124 woo-hoo
2.4.18-19.7.xsmp 128 not bad for frankenstein's montster
2.5.59-mm5 157 uh-oh

HP LH3000 U3. Dual 866 Mhz Intel Pentium III, 2GB ram. megaraid
controller with two channels, each channel raid 5 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 for Oracle redo-log (in a log 'group').

Oracle version 8.1.7 (no aio support in this release) is accessing
datafiles on the two megaraid devices via /dev/raw stacked on top of

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.

I'll test any kernel you throw my way.


| David Mansfield |
| |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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