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

Re: Processor speed relative to postgres transactions per second

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Chris Barnes <compuguruchrisbarnes(at)hotmail(dot)com>
Cc: Postgres General Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Processor speed relative to postgres transactions per second
Date: 2010-03-29 18:20:41
Message-ID: 4BB0EF79.1030604@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-general
Recently I ran a set of tests on two systems:  a 4-core server with 5 
disks (OS + WAL + 3 for DB) on a battery backed disk controller, and a 
newer Hyper-threaded design with 4 physical cores turning into 8 virtual 
ones--but only a single disk and no RAID controller, so I had to turn 
off its write cache to get reliable database operation.  (See 
http://www.postgresql.org/docs/current/interactive/wal-reliability.html )

When running pgbench with its simple built-in SELECT-only test, on a 
tiny data set that fits in RAM, I went from a peak of 28336 TPS on the 
4-core system to a peak of 58164 TPS on the 8-core one.

On the default write-heavy test, the 4-core server peaked at 4047 TPS.  
The 8-core one peaked at 94 TPS because that's as fast as its single 
disk could commit data.

The moral is that a faster processor or more cores only buys you 
additional speed if enough of your data fits in RAM that the processor 
speed is the bottleneck.  If you're waiting on disks, a faster processor 
will just spin without any work to do.  You can't answer "will I get 
more transactions per second?" without specifying what your transaction 
is, and knowing what the current limiter is.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us


In response to

pgsql-general by date

Next:From: Greg SmithDate: 2010-03-29 18:41:50
Subject: Re: playr (or similar tool)?
Previous:From: John GageDate: 2010-03-29 18:12:47
Subject: Re: How long will the query take

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