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@xxxxxxxxxxxxxxx www.2ndQuadrant.us
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
