Are we in the ballpark? - Mailing list pgsql-performance
From | Wayne Conrad |
---|---|
Subject | Are we in the ballpark? |
Date | |
Msg-id | 4D48A3E6.6080904@databill.com Whole thread Raw |
Responses |
Re: Are we in the ballpark?
|
List | pgsql-performance |
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?
pgsql-performance by date: