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

Re: Large (8M) cache vs. dual-core CPUs

From: Gavin Hamill <gdh(at)laterooms(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Large (8M) cache vs. dual-core CPUs
Date: 2006-04-25 18:35:01
Message-ID: 20060425193501.52b14860.gdh@laterooms.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, 25 Apr 2006 14:14:35 -0400
Bill Moran <wmoran(at)collaborativefusion(dot)com> wrote:

> Does anyone in the PostgreSQL community have any experience with
> large caches or dual-core pentiums that could make any
> recommendations? 

Heh :) You're in the position I was in about a year ago - we "naturally"
replaced our old Dell 2650 with £14k of Dell 6850 Quad Xeon with 8M
cache, and TBH the performance is woeful :/

Having gone through Postgres consultancy, been through IBM 8-way POWER4
hardware, discovered a bit of a shortcoming in PG on N-way hardware
(where N is large) [1] , I have been able to try out a dual-dual-core
Opteron machine, and it flies.

In fact, it flies so well that we ordered one that day. So, in short
£3k's worth of dual-opteron beat the living daylights out of our Xeon
monster. I can't praise the Opteron enough, and I've always been a firm
Intel pedant - the HyperTransport stuff must really be doing wonders. I
typically see 500ms searches on it instead of 1000-2000ms on the Xeon)

As it stands, I've had to borrow this Opteron so much (and send live
searches across the net to the remote box) because otherwise we simply
don't have enough CPU power to run the website (!)

Cheers,
Gavin.

[1] Simon Riggs + Tom Lane are currently involved in optimisation work
for this - it turns out our extremely read-heavy load pattern reveals
some buffer locking issues in PG.

In response to

pgsql-performance by date

Next:From: Jim C. NasbyDate: 2006-04-25 18:35:22
Subject: Re: Slow queries salad ;)
Previous:From: Scott MarloweDate: 2006-04-25 18:33:38
Subject: Re: Large (8M) cache vs. dual-core CPUs

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