Skip site navigation (1) Skip section navigation (2)

Re: Advice sought : new database server

From: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Craig James <cjames(at)emolecules(dot)com>, Rory Campbell-Lange <rory(at)campbell-lange(dot)net>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Advice sought : new database server
Date: 2012-03-08 12:43:10
Message-ID: CA+CSw_udgmESYpkFJ_nDpkom6t+JTQsEtdzH0D8C6bXvrU6OHQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Wed, Mar 7, 2012 at 10:18 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> those numbers are stupendous for 8 drive sata.  how much shared
> buffers do you have?

Couple of things to notice:
1) The benchmark can run fully in memory, although not 100% in shared_buffers.
2) These are 100k transaction runs, meaning that probably no
checkpointing was going on.
3) Given the amount of memory in the server, with  dirty flush
settings the OS will do mostly sequential writes.

Just ran a quick test. With synchronous_commit=off to simulate a BBU I
have no trouble hitting 11k tps on a single SATA disk. Seems to be
mostly CPU bound on my workstation (Intel i5 2500K @ 3.9GHz, 16GB
memory), dirty writes stay in OS buffers, about 220tps/6MBps of
traffic to the xlog's, checkpoint dumps everything to OS cache which
is then flushed at about 170MB/s (which probably would do nasty things
to latency in real world cases). Unlogged tables are give me about 12k
tps which seems to confirm mostly CPU bound.

So regardless if the benchmark is a good representation of the target
workload or not, it definitely isn't benchmarking the IO system.

Ants Aasma

In response to

Responses

pgsql-performance by date

Next:From: Rory Campbell-LangeDate: 2012-03-08 13:27:37
Subject: Re: Advice sought : new database server
Previous:From: Shaun ThomasDate: 2012-03-07 22:24:25
Subject: Re: Advice sought : new database server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group