Re: Looking for installations with a large number of concurrent users

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Looking for installations with a large number of concurrent users
Дата
Msg-id 4A2F9BA502000025000277F8@gw.wicourts.gov
обсуждение исходный текст
Ответ на Looking for installations with a large number of concurrent users  (David Kerr <dmk@mr-paradox.net>)
Ответы Re: Looking for installations with a large number of concurrent users  (David Kerr <dmk@mr-paradox.net>)
Список pgsql-performance
David Kerr <dmk@mr-paradox.net> wrote:

> We'll be on 8.4 (or 8.5) by the time we go live and SLES linux (for
> now).  I don't have hardware yet, basically, we'll purchase enough
> hardware to handle whatever we need...
>
> Is anyone willing to share their max connections and maybe some
> rough hardware sizing (cpu/mem?).

We're on SLES 10 SP 2 and are handling a web site which gets two to
three million hits per day, running tens of millions of queries, while
functioning as a replication target receiving about one million
database transactions to modify data, averaging about 10 DML
statements each, on one box with the following hardware:

16 Xeon X7350 @ 2.93GHz
128 GB RAM
36 drives in RAID 5 for data for the above
2 mirrored drives for xlog
2 mirrored drives for the OS
12 drives in RAID 5 for another database (less active)
a decent battery backed RAID controller, using write-back

This server also runs our Java middle tiers for accessing the database
on the box (using a home-grown framework).

We need to run three multiprocessor blades running Tomcat to handle
the rendering for the web application.  The renderers tend to saturate
before this server.

This all runs very comfortably on the one box, although we have
multiples (in different buildings) kept up-to-date on replication,
to ensure high availability.

The connection pool for the web application is maxed at 25 active
connections; the replication at 6.  We were using higher values, but
found that shrinking the connection pool down to this improved
throughput (in a saturation test) and response time (in production).
If the server were dedicated to PostgreSQL only, more connections
would probably be optimal.

I worry a little when you mention J2EE.  EJBs were notoriously poor
performers, although I hear there have been improvements.  Just be
careful to pinpoint your bottlenecks so you can address the real
problem if there is a performance issue.

-Kevin

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matthew Wakeling
Дата:
Сообщение: Re: Explaining an EXPLAIN.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GiST index performance