Re: Problems with max_connections parameter

Поиск
Список
Период
Сортировка
От Jorge Augusto Meira
Тема Re: Problems with max_connections parameter
Дата
Msg-id AANLkTimdAcRvgT2PrtnxkR6jRdOPH5G0Jadkv4am7KzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Problems with max_connections parameter  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Problems with max_connections parameter  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Hi

Thanks for the answers.

Really, I didn't showed you basic informations.

I used the PostgreSQL 8.4. The server configuration was:
       Processor: Intel Xeon Processor W3570 Quad Core Processor
       Mem: 20GB
       Network Interface: Gigabit
       HD: 12 x 1 TB (RAID1+0)
       OS: Debian GNU/Linux, kernel 2.6.26-2-64

The client machines has similar configuration.

The error message was:
"Erro Conex=E3o: A tentativa de conex=E3o falhou."
or
"Erro Conex=E3o: FATAL: connection limit exceeded for non-superusers"

I used the logs of my java application used to simulate the clients.

Thanks
Jorge

On Fri, Dec 3, 2010 at 12:54 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov
> wrote:

> Euler Taveira de Oliveira <euler@timbira.com> wrote:
>
> > Talking about your problem, are you sure you're not reaching
> > max_connections?
>
> It also strikes me that from the minimal information given, it might
> be possible that pid numbers or port numbers are wrapping around
> before the OS is ready to allow re-use.  I haven't seen that
> behavior except in machines infected with a worm, but this test
> might be edging into the same territory if it's using a new
> connection for each request.  Obviously, nobody who cared about
> performance would use that technique in production, but it rather
> sounds like this test does.
>
> -Kevin
>

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

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: BUG #5783: plpythonu bool behavior change
Следующее
От: tmoore
Дата:
Сообщение: Re: TRUNCATE HANGS