Re: CPUs for new databases
От | Christian Elmerot |
---|---|
Тема | Re: CPUs for new databases |
Дата | |
Msg-id | 4CC6F276.30603@one.com обсуждение исходный текст |
Ответ на | Re: CPUs for new databases ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-performance |
On 2010-10-26 16:27, Kevin Grittner wrote: > Christian Elmerot<ce@one.com> wrote: > >> What is the general view of performance CPU's nowadays when it >> comes to PostgreSQL performance? Which CPU is the better choice, >> in regards to RAM access-times, stream speed, cache >> synchronization etc. Which is the better CPU given the limitation >> of using AMD64 (x86-64)? > > You might want to review recent posts by Greg Smith on this. One > such thread starts here: > > http://archives.postgresql.org/pgsql-performance/2010-09/msg00120.php I've read those posts before and they are interresting but only part of the puzzle. > >> We're getting ready to replace our (now) aging db servers with >> some brand new with higher core count. The old ones are 4-socket >> dual-core Opteron 8218's with 48GB RAM. Right now the disk-subsystem >> is not the limiting factor so we're aiming for higher core-count >> and as well as faster and more RAM. We're also moving into the >> territory of version 9.0 with streaming replication to be able to >> offload at least a part of the read-only queries to the slave >> database. The connection count on the database usually lies in the >> region of ~2500 connections and the database is small enough that >> it can be kept entirely in RAM (dump is about 2,5GB). > > You really should try connection pooling. Even though many people > find it counterintuitive, it is likely to improve both throughput > and response time significantly. See any of the many previous > threads on the topic for reasons. I believe you are right as this is actually something we're looking into as we're making read-only queries pass through a dedicated set of lookup-hosts as well as having writes that are not time critical to pass through another set of hosts. Regards, Christian Elmerot
В списке pgsql-performance по дате отправления: