Re: Problems with max_connections parameter - Mailing list pgsql-bugs

From Jorge Augusto Meira
Subject Re: Problems with max_connections parameter
Date
Msg-id AANLkTimdAcRvgT2PrtnxkR6jRdOPH5G0Jadkv4am7KzA@mail.gmail.com
Whole thread Raw
In response to Re: Problems with max_connections parameter  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Problems with max_connections parameter  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: BUG #5783: plpythonu bool behavior change
Next
From: tmoore
Date:
Subject: Re: TRUNCATE HANGS