Skip site navigation (1) Skip section navigation (2)

Re: Scalability in postgres

From: Fabrix <fabrixio1(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Scalability in postgres
Date: 2009-05-28 22:13:41
Message-ID: dedbc5820905281513h4f60e0cdxda9ab145531d581b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
2009/5/28 Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>

> On Thu, May 28, 2009 at 4:53 PM, Fabrix <fabrixio1(at)gmail(dot)com> wrote:
>
>>
>>
>>>
>>> Wow, that's some serious context-switching right there - 300k context
>>> switches a second mean that the processors are spending a lot of their
>>> time fighting for CPU time instead of doing any real work.
>>
>>
>   There is a bug in the quad core chips during a massive amount of
> connections that will cause all cores to go to 100% utilization and no work
> be done.  I'm digging to find links, but if I remember correctly, the only
> way to fix it was to disable the 4th core in linux (involved some black
> magic in /proc).  You really need to lower the number of processes you're
> forcing each processor bus to switch through (or switch to AMD's
> hyper-transport bus).
>

The server HP is already AMD  proccesor.
The server with 4 dual core had max_connections = 5000 too, but the maximum
of connections at time were 1800 and work very well.

If you get the link on the bug's quad core I would greatly appreciate

>
>
>>
>>>
>>> It appears that you have the server configured with a very high number
>>> of connections as well?  My first suggestion would be to look at a way
>>> to limit the number of active connections to the server at a time
>>> (pgPool or similar).
>>
>>
>> yes, i have max_connections = 5000
>> can lower, but at least i need 3500 connections
>>
>
> Typically, it's a bad idea to run run with anything over 1000 connections
> (many will suggest lower than that).  If you need that many connections,
> you'll want to look at a connection pool like pgBouncer or pgPool.
>


Postgres does not support more than 1000? even the server is very robust?
I will try to lower... and already i have a pool (not pgpool and not
pgBouncer). I have distributed all connections in three servers :).

>
> --Scott
>
>
>

In response to

pgsql-performance by date

Next:From: Anne RossetDate: 2009-05-28 22:46:43
Subject: Unexpected query plan results
Previous:From: FabrixDate: 2009-05-28 21:28:01
Subject: Re: Scalability in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group