DB-14: Tales of the Bunker - 2005 Gus Björklund, Progress Software Corporation John Harlow,...

DB-14: Tales of the Bunker - 2005

Gus Björklund, Progress Software Corporation

John Harlow, Bravepoint, Inc.

Dan Foreman, Bravepoint, Inc.

Rich Banville, Progress Software Corporation

© 2006 Progress Software Corporation3DB-14 Tales of the Bunker 2005

Goals of the Bunker Test

Find the optimal way to run Progress® on Linux

Test various ideas and theoriesHave funBunker 2005:

• Pre-release 10.1A• 64-bit AMD• Performance of Utilities• Investigate “coma” problem• Network speed effects


Why Linux?


Bunker 2005 Team

Gus Björklund, Wizard, Progress Software• Progress User since 1989

John Harlow, President of BravePoint• Progress User since 1984

Dan Foreman• Progress User since 1984

Rich Banville, Fellow, Progress Software• Progress User since 1993


The ATM Benchmark Environment


The ATM Benchmark

Simulates teller machine transactions• deposit or withdrawal• heavy database update workload

Each transaction• does 3 fetches, 3 updates, 1 create

– retrieve and update account, branch, and teller rows– create a history row

Run “n” transaction generators• concurrently• for fixed time period• count total number of transactions performed


Test Database (logical)

Table Number of Rows

Account 80,000,000 (100 bytes each)

Teller 80,000 (100 bytes each)

Branch 8,000 (100 bytes each)

History add 1 per transaction (50 bytes each)


Test Database (physical)

Total size 12 gigabytes (data)

Data extent size 2,000,000 (2 GB)

Data extent count 6

Data block size 4096 bytes

Rows per block 64

Data Areas 1, Type II

Data cluster size 512 blocks (2 megabytes)


Test Database (other info)

Account table data 9.2 gigabytes

Branch table data 922 kilobytes

Teller table data 9.3 megabytes

Indexes 691 megabytes

RM blocks 2,669,712

Index blocks 178,463

Free blocks 150,682


Equipment


Server 1: hostname “uniblab”

Operating System SuSE LinuxEnterprise Server 9

Cpus 2 x 2.8 GHz Intel Xeon

Motherboard IBM xSeries

Memory 4 gigabytes

Disk drives on controller 6 x n GB 10,000 rpm USCSI


Server 3: hostname “hal”

Operating System SuSE Linux 10.0

Cpus 2 x 2.4 GHz Intel Xeon

Memory 2 gigabytes

Disk drives on motherboard 1 x n GB 7200 rpm SATA

Disk drives on controller 6 x n GB 7200 rpm SATA


Server 3: hostname “jumbo”

Operating System SuSE Linux 10.0

Cpus 2 x AMD 64-bit 2.0 GHzDual Core

Motherboard Asus K8N-DL

Disk controller 3Ware 9500S-8

Memory 6 gigabytes

Disk drives on motherboard 2 x 160 GB Maxtor7200 rpm Ultra IDE

Disk drives on controller 8 x 164 GB Hitachi Deskstar7200 rpm SATA II


AMD-64 Hyper-Transport Design


Bunker Network Components

3 server machines

Netgear GS 105 Gigabit switch

SMC Barricade WAP

LinkSys WVC11b “bunker cam”

Various laptops running• Windoze• Linux• Mac OS X 10.3


Bunker Network (partial)

hal uniblab jumbo

gigabit switch

wap bunker Cam

Internetrouter

laptops

servers


Other Equipment


Past Results


Lessons from Past Bunkers

Type II Data Areas are fasterDon’t use Reiser File SystemUse EXT3 or XFS File SystemDon’t use the Anticipatory Scheduler

• Deadline or CFQ is better

2.6 Kernel is faster than 2.4 KernelFor RAID 10, the Largest Possible Stripe Size was

always the fastest, both Software & Hardware Striping

Very good performance at low cost


This Year’s (October 2005)Bunker Results


Setup Results

db load time 30 minutes

db load rate 2.7 million rows per minute

dbanalysis 3 min 55 sec

idxbuild (-threads 1) 8 min 54 sec

idxbuild scratch 1,129,764 KB

prorest (from disk) 9 minutes

Database is about 11 gigabytes


Baseline Server Configuration

Data extents on striped array, BI log on own diskBI cluster size: 16384BI blocksize: 16Server options:

– -n 200 -L 10240– -B 64000– -spin 50000– -bibufs 32

Page writers: 4BI writer: yesAI writer: no


Linux I/O schedulers - 64-bit AMD SuSE 10

183

872

0

200

400

600

800

1000

CFQ deadline

thro

ugh

put

(tps)

What do we learn from this?


Dump/Load

-index 0 Option on Binary Dump• Excellent Performance Improvement• But order of records may not be what you want


Dump/Load with -RO

OpenEdge® 10 -RO: Faster than V9• V9 with -RO: faster than without

OpenEdge 10 with -RO: performance same as without

OpenEdge 10 -RO: Clients now write entries in the .lg file


Dump/Load

Logical Scatter Factor is very important• Performance Difference of 400% to 1000%


Remote Clients

-Ma• The Lower Value, the Better the Performance

-Mm• No Negative Impact on ATM Benchmarks


Network Speed

20

7090 100

020406080

100120140

Relative Performance

thro

ugh

put

(perc

ent)


“Coma” Problem

We have experienced this problem in every Bunker Test

We still don’t know what’s wrongA customer on RH AS 4 Kernel: 2.6.9-5.Elsmp

reports problem solved - for himThere are an infinite number of things and

combinations of things that can be changed in the kernel

We need to do some work with the “aggressiveness” of the APWs to help…but also more testing


Coma problem: -directio helps

843680

0

200

400

600

800

1000

no -directio with -directio

thro

ugh

put

(tps)


We still think about this problem


64-Bit

We saw

No difference in general performancebetween 32 and 64 bit Progress


Strange Problem

WEIRD PROBLEM ON ONE MACHINE:The bigger –B, the lower the TPS rate

• True with both 32 and 64 bit Progress/Linux• Could be caused by:

– Enterprise versus Desktop version of Linux– 10.1A Beta problem– SUSE Linux 10 issue (unsupported OS)– Something else– HyperTransport Effects– All the above

DID NOT OCCUR ON OTHER MACHINESHAVE NOT SEEN AGAIN


TPS vs Response Time

901815 748

0

200

400

600

800

1000

Max TPS AggrApws

Direct I/O

TP

S v

s M

ax

Resp

onse

Column 1 Max R x 10

Avg Response time 0.2 seconds


V10.0B versus V10.1A Beta

No Difference in general performance


SATA versus SCSI

SCSI was faster

SATA is less expensive

Beware: desktop drives not rated for 24x7 operation


Online backup time

241

836

0

200

400

600

800

1000

no users 150 user atm

bac

kup

time (

seco

nds

)

workload


Online backup rate (approximate)

2804

808

0

5001000

15002000

2500

30003500

4000

no users 150 user atm

back

up r

ate

(MB

per

min

ute)

workload


Online backup performance impact

493592

0

200

400

600

800

1000

with onlinebackup

no onlinebackup

thro

ugh

put

(tps)

150 user atm workload


Adding extent online: elapsed time

• Add 2 GB extent on same disk array

operation no users 150 users

create extent 18 seconds 35 seconds

enable extent 0 seconds 0 seconds


Adding extent online: performance impact

839 784

0

200

400

600

800

1000

normal adding extent

thro

ugh

put

(tps)

150 user workload, add 2 GB data extent online,Extent on same striped array as other extents


Secret Bunker Web Pages

March 2002 & October 2002http://www.myfloridacottage.com/benchmark.html

April 2004http://www.myfloridacottage.com/bunker3.html

Oct 2005http://www.myfloridacottage.com/bunker4/


Join Us in the Bunker

Film


Also seeGus’s RDBMS Tuning Guide on

conference CD

Want Answers

DB-14: Tales of the Bunker - 2005 Gus Björklund, Progress Software Corporation John Harlow,...

Documents

Transcript of DB-14: Tales of the Bunker - 2005 Gus Björklund, Progress Software Corporation John Harlow,...