Message-ID: <4BB0E267.3030804@2ndquadrant.com>
Date: Mon, 29 Mar 2010 13:24:55 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Ramiro Barreca <rbarreca@gmail.com>
CC: pgsql-admin@postgresql.org
Subject: Re: Virtualization vs. sharing a server
References: <b1fec7231003290750n3326e86bs6521de808c7d504c@mail.gmail.com>
In-Reply-To: <b1fec7231003290750n3326e86bs6521de808c7d504c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ramiro Barreca wrote:
>
>    1. Is there a configuration option we need to consider to share
>       this server?
>

The two main configuration options that impact how much RAM PostgreSQL 
uses are shared_buffers and work_mem.  If the server is shared, you just 
need to avoid tuning those upwards as far as you would on a dedicated 
system.  The defaults for both are tiny, so unless you've already pushed 
these upwards a lot you're unlikely to have any issues in an initial 
deployment.


>    1. What is the recomended hardware for a PostgreSQL server that has
>       to support between 500 and 1000 simultaneous user connections?
>       Is there a whitepaper about this?
>

The recommendation is "try not to do that".  PostgreSQL connections are 
fairly expensive, and scaling into hundreds of connections on a single 
system tends to break down due to connection creation/teardown 
overhead.  You should be investigating a connection pooler to put in 
between the application and the database, limiting the number of 
connections to something much smaller.  PgBouncer is most people's first 
choice for this scale of database:  http://pgfoundry.org/projects/pgbouncer

Once you've gotten past that issue, recommended hardware varies greatly 
depending on workload.  Read vs. write balance?  Size of the critical 
working set in RAM?  Size of the database?  Peak commit rate?  Types of 
queries executed by the application?  It all factors into the decision.

Add in business requirements for reliability and the inevitable vendor 
preference, you're likely to end up with a stack of possible 
configurations you could consider to sort through.  There is no generic 
recommendation for larger systems.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us