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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-03-29 18:41:50 | Re: playr (or similar tool)? |
Previous Message | John Gage | 2010-03-29 18:12:47 | Re: How long will the query take |