pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: J. Andrew Rogers <jrogers@neopolitan.com>
To: Christian.Kastner@gutmann.at
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql Hardware - Recommendations
Date: Tue, 06 Sep 2005 00:03:29 -0700
Message-ID: <BF428D51.2A1E%jrogers@neopolitan.com> (raw)
In-Reply-To: <D5550E881896C946B5D2524C265CF95B2272FC@aut-vie-w3s006.bankgutmann.co.at>




On 9/5/05 6:50 AM, "Christian.Kastner@gutmann.at"
<Christian.Kastner@gutmann.at> wrote:
> The questions we are asking us now are:
> 
> 1) Intel or AMD (or alternate Platform)
> Are we better of with Xeons or Opterons? Should we consider the IBM
> OpenPower platform?


Opteron spanks Xeon for database loads.  Advantage AMD, and you generally
won't have to spend much extra money for the privilege.  I've never used
Postgres on the IBM OpenPower platform, but I would expect that it would
perform quite well, certainly better than the Xeons and probably competitive
with the Opterons in many respects -- I am not sufficiently knowledgeable to
make a definitive recommendation.

 
> 2) CPUs vs cache
> Would you rather have more CPUs or more cache? Eg: 4x Xeon 1MB vs 2x
> Xeon 8MB


I would expect that cache sizes are relatively unimportant compared to
number of processors, but it would depend on the specifics of your load.
Cache coherence is a significant issue for high concurrency database
applications, and a few megabytes of cache here and there will likely make
little difference for a 60GB database.  Databases spend most of their time
playing in main memory, not in cache.  The biggest advantage I can see to
bigger cache would be connection scaling, in which case you'll probably buy
more mileage with more processors.

There are a lot of architecture dependencies here.  Xeons scale badly to 4
processors, Opterons scale just fine.


 
> 3) CPUs vs Memory
> Would you rather have 4x CPUs and 8GB of memory, or 2x CPUs with 16GB of
> memory?


Uh, for what purpose?  CPU and memory are not fungible, so how you
distribute them depends very much on your application.  You can never have
too much memory for a large database, but having extra processors on a
scalable architecture is pretty nice too.  What they both buy you is not
really related.  

The amount of memory you need is determined by the size of your cache-able
working set and the nature of your queries.  Spend whatever money is left on
the processors; if your database spends all its time waiting for disks, no
quantity of processors will help you unless you are doing a lot of math on
the results.


YMMV, as always.  Recommendations more specific than "Opterons rule, Xeons
suck" depend greatly on what you plan on doing with the database.


Cheers,

J. Andrew Rogers






view thread (4+ messages)  latest in thread

Message-ID: <BF428D51.2A1E%jrogers@neopolitan.com>
Permalink:  ../BF428D51.2A1E%25jrogers@neopolitan.com/
Also on:    postgresql.org/message-id/BF428D51.2A1E%jrogers@neopolitan.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jrogers@neopolitan.com, Christian.Kastner@gutmann.at
  Subject: Re: Postgresql Hardware - Recommendations
  In-Reply-To: <BF428D51.2A1E%jrogers@neopolitan.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox