Linux 2.6 Durability Test Using OSDL-DBT-3

To test Linux 2.6.0 durability, we stressed the OS under OSDL-DBT-3 workload for 14 days. OSDL-DBT-3 is a database workload for decision support system. The database is of about 40G, and there were 8 database connections during the test feeding the database with query streams.

During the 14-day test, we did not see any kernel failure. Linux 2.6 kernel passed the durability test under the OSDL-DBT-3 workload.

About OSDL-DBT-3

OSDL-DBT-3 simulates a workload of a decision support system. It models complex business analysis applications that produce refined data to support the making of sound business decisions. The simulated business model is a wholesale supplier, for example, a car rental agency or food distributor, that must manage, sell or distribute a product worldwide. Its origin is the Transaction Processing Performance Council's TPC-H (tm) benchmark.

OSDL-DBT-3 consists of three tests: The load test builds the database. The measurement for the the load test is the database load time.

The power test is designed to measure the raw query execution power of the system. It is driven by a single active user and sequentially executes the twenty-two queries. The metrics for the power test is the query processing power.

The throughput test is designed to measure the ability of the system to process the most queries in the least amount of time. There are always at least two streams and at most ten depending on the scale factor. The throughput test must be executed in parallel with several pairs of refresh functions. The metrics for the throughput test is the throughput numerical quantity.

The workload can run on RDBMS software SAPDB and PostgreSQL. The workload test kit was written to operate in a one-tier environment and exercises kernel locks, raw I/O(for SAPDB), file system I/O(for PostgreSQL), memory management, and the scheduler. The stress of the system is dependent upon the database scale factor(which directly maps to database table size) and the number of streams in the throughput test.

The Durability Test

To test the durability of Linux kernel 2.6, we run the throughput test 5 times(last for 14 days) against a PostgreSQL database of scale factor 10.

Hardware Configuration

8 CPUS @ 700.183 MHz

CPU model Pentium III (Cascades)

16605236 kB Memory

The database is on a RAID0 drive consists of 14 disks on 2 channels. The disks are NEC GEM359, the driver is LSI Logic MegaRAID H01.07. The partition is of 118G with EXT3 file system.

PostgreSQL WAL(Write Ahead Log) is put on a separate disk with EXT3 file system. During the run, PostgreSQL uses temporary spaces for sorting, the temporary spaces are put on a separate disk with EXT3 file system.

Software Configuration

Linux Kernel: 2.6.0-test7 with deadline scheduler

PostgreSQL: 7.3.3

sysstat: 4.1.2

procps: 3.1.5

Database Configuration

The database is of scale factor 10. After loading the data and creating the indexes, the database takes about 40G of disk space.

Run Configuration

Run Throughput run with 8 streams back to back 5 times. At the end of each run, use PostgreSQL vaccuum to clean up the database so that the database size will not accumulate after the test.

Results of the Runs

Each throughput test finished between 2 days 16 hour to 2 days 22 hours. During the 14-day test, we did not see any kernel failure. Linux 2.6 kernel passed the durability test under the OSDL-DBT-3 workload. However, we do see performance degradation throughout the test(as much as 8% from the first to the last run).

The following table summarizes the 5 runs and the throughput metric(Throughput Numeric Quantity).

Run # Host Name PLM # Kernel Name dbt3-throughput Average dbt3-throughput dbt3-throughput changes
1 dev8-001

2203

2.6.0-test7

27.50

27.5 0.00%
2 dev8-001

2203

2.6.0-test7

27.34

27.34 -0.58 %
3 dev8-001

2203

2.6.0-test7

26.31

26.31 -4.33 %
4 dev8-001

2203

2.6.0-test7

25.24

25.24 -8.22 %
5 dev8-001

2203

2.6.0-test7

25.10

25.1 -8.73 %

The test stressed I/O and memory management system. I/O and memory were the performance bottleneck. All 16G of memory is used as buffer or cache. The CPU was about 80% busy during the test, most of which were wait-for-I/O.

The following are the graphs based on the vmstat taken every 5 minutes during the test. Each graph represents one throughput run. The x-axis is time in 5 minutes.

vmstat header link to plot
the amount of idle memory (kB) free
the amount of memory used as buffers (kB) buff
the amount of memory used as cache (kB) cache
Blocks received from a block device (blocks/s) bi
Blocks sent to a block device (blocks/s) bo
user time, including nice time us
system time sy
idle, Prior to Linux 2.5.41, this includes IO-wait time id
Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero wa


Copyright © 2003 Open Source Development Labs, Inc.
Verbatim copying of this document or portions of this document
is permitted in any medium, provided this notice is included.