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
|
Список | 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 по дате отправления: