Re: Processor speed relative to postgres transactions per second

On Mon, Mar 29, 2010 at 11:00 AM, Steve Atkins <steve(at)blighty(dot)com> wrote:
> For larger databases, IO speed is the bottleneck more often than not. In those cases throwing memory, better disk controllers and faster / more drives at them will improve things. More CPU will not.

We're in the situation where we are CPU bound on a dual 4 core 2.1GHz
opteron, and IO wait is never more than one CPU's worth (12%). That's
on the slony source server. The destination servers are even more CPU
bound, with little or no IO wait.

The RAID array is a RAID-10 with 12 drives, and a RAID-1 with two for
pg_xlog. The RAID-1 pair is running at about 30 megabytes per second
written to it continuously. It can handle sequential throughput to
about 60 megabytes per second.

Of course, if we put more CPU horsepower on that machine, (mobo
replacement considered) then I'm sure we'd start getting IO bound, and
so forth.

> Also, the price/speed curve for CPUs is not pretty at the higher end. You can get a lot of RAM or disk for the price difference between the fastest and next fastest CPU for any given system.

Agreed. The curve really starts to get ugly when you need more than 2
sockets. Dual socket 6 and 8 core cpus are now out, and not that
expensive. CPUs that can handle being in a 4 to 8 socket machine are
two to three times as much for the same basic speed. At that point
it's a good idea to consider partitioning your data out into some
logical manner across multiple machines.