Re: Urgent: 10K or more connections

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: Urgent: 10K or more connections
Дата
Msg-id Pine.LNX.4.33.0307181005290.2220-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: Urgent: 10K or more connections  (Doug McNaught <doug@mcnaught.org>)
Ответы Re: Urgent: 10K or more connections  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On 18 Jul 2003, Doug McNaught wrote:

> Francois Suter <dba@paragraf.ch> writes:
>
> > Hi all,
> >
> > I have received a question via the Advocacy site and I am not knowledgeable
> > enough to answer. Can you help?
> >
> > The question is: can PostgreSQL handle between 10'000 and 40'000
> > simultaneous connections? The persone asking the question has to choose
> > between Oracle and PostgreSQL, and my guess is that they would be relieved
> > if they could go with PostgreSQL.
>
> On a big enough system, sure.  Each PG connection backend is a
> separate process, so you'd need to make sure the process table was big
> enough, open file and shared memory limits set high, etc.  You'd want
> a really big machine, hopefully 64-bit like a Sparc or IA64, with lots
> of memory.  But you'd want that for Oracle, too.
>
> You'd definitely want to spend a lot of time tuning and testing for
> that activity level, but again, you'd do that for Oracle too.

I'm gonna go out on a limb and guess that if you want 10k concurrent
connections, you're likely gonna be spending some time here on the list
getting postgresql to perform in that environment.  I.e. little
inefficiencies in shared memory access and IPC are gonna cause this to
crawl even on a Sun E10k with 64 CPUs and 64 gigs of ram.

But I'm sure that with a few tweaks to the code here and there it's
doable, just don't expect it to work "out of the box".


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

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: FATAL 2: open of /var/lib/pgsql/data/pg_clog/0EE3
Следующее
От: Dmitry Tkach
Дата:
Сообщение: Re: FATAL 2: open of /var/lib/pgsql/data/pg_clog/0EE3