On Mon, Mar 29, 2010 at 11:00 AM, Steve Atkins <st...@blighty.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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
