From: Wayne Conrad <wayne@databill.com>
To: pgsql-performance@postgresql.org
Subject: Are we in the ballpark?
Date: Tue, 01 Feb 2011 17:23:02 -0700
Message-ID: <4D48A3E6.6080904@databill.com> (raw)
We're building a new database box. With the help of Gregory Smith's
book, we're benchmarking the box: We want to know that we've set it up
right, we want numbers to go back to if we have trouble later, and we
want something to compare our _next_ box against. What I'd like to know
is, are the performance numbers we're getting in the ballpark for the
class of hardware we've picked?
First, the setup:
CPU: Two AMD Opteron 6128 (Magny-Cours) 2000 mHz, eight cores each
RAM: DDR3-1333 64 GB (ECC)
RAID: 3Ware 9750 SAS2/SATA-II PCIe, 512 MB battery backed cache,
write-back caching enabled.
Drives: 16 Seagate ST3500414SS 500GB 7200RPM SAS, 16 MB cache:
2 RAID1 ($PG_DATA/xlog)
12 RAID10 ($PG_DATA)
2 hot spare
PostgreSQL 8.4.1 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.3.real
(Debian 4.3.4-2) 4.3.4, 64-bit
File system: XFS (nobarrier, noatime)
i/o scheduler: noop
Database config (differences from stock that might affect performance):
shared_buffers = 8192MB
temp_buffers = 16MB
work_mem = 192MB
maintenance_work_mem = 5GB
wal_buffers = 8MB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
random_page_cost = 1.0
constraint_exclusion = on
Now, the test results:
Memtest86+ says our memory bandwidth is:
L1 32,788 MB/S
L2 is 10,050 MB/S
L3 is 6,826 MB/S
Stream v5.9 says:
1 core: 4,320
2 cores: 8,387
4 cores: 15,840
8 cores: 23,088
16 cores: 24,286
Bonnie++ (-f -n 0 -c 4)
$PGDATA/xlog (RAID1)
random seek: 369/sec
block out: 87 MB/sec
block in: 180 MB/sec
$PGDATA (RAID10, 12 drives)
random seek: 452
block out: 439 MB/sec
block in: 881 MB/sec
sysbench test of fsync (commit) rate:
$PGDATA/xlog (RAID1)
cache off: 29 req/sec
cache on: 9,342 req/sec
$PGDATA (RAID10, 12 drives)
cache off: 61 req/sec
cache on: 8,191 req/sec
pgbench-tools:
Averages for test set 1 by scale:
avg_
set clients tps latency 90%< max_latency
1 1 29141 0.248 0.342 5.453
1 10 31467 0.263 0.361 7.148
1 100 31081 0.265 0.363 7.843
1 1000 29499 0.278 0.365 11.264
Averages for test set 1 by clients:
avg_
set clients tps latency 90%< max_latency
1 1 9527 0.102 0.105 1.5
1 2 13850 0.14 0.195 5.316
1 4 19148 0.19 0.251 2.228
1 8 44101 0.179 0.248 2.557
1 16 50311 0.315 0.381 11.057
1 32 47765 0.666 0.989 24.076
We've used Brad Fitzpatrick's diskchecker script to show that the i/o
stack is telling the truth when it comes to fsync.
Are there any nails sticking up that we need to pound on before we start
more extensive (real-world-ish) testing with this box?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: wayne@databill.com
Subject: Re: Are we in the ballpark?
In-Reply-To: <4D48A3E6.6080904@databill.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox