Message-ID: <55073680.7090104@BlueTreble.com>
Date: Mon, 16 Mar 2015 15:01:04 -0500
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "michael@sqlexec.com" <michael@sqlexec.com>, Tomas Vondra
 <tomas.vondra@2ndquadrant.com>
CC: <pgsql-performance@postgresql.org>
Subject: Re: MusicBrainz postgres performance issues
References: <B008F2EE-45D7-4535-9163-56A8CDCA553C@musicbrainz.org>
 <CAB6McgXxZdD6yuYRLg4tgDdhqzXKLs63aV+S_nOfZ9arSXUAhA@mail.gmail.com>
 <9E71CCBE-4CDF-482E-878D-6C16027B6283@musicbrainz.org>
 <20150315135022.GC19792@alap3.anarazel.de>
 <CAOR=d=0YwcnVi3kGD21W7jYjE7DcWjp0v0GjncH-c2-oJEP5Rw@mail.gmail.com>
 <CAOR=d=1Axcbj2VcUO=5tM1nv6RjuA0D+av5+Mt7RTztgTxaMnA@mail.gmail.com>
 <20150315172048.GG9324@alap3.anarazel.de>
 <CAG95seXv4EKGhDV04rkk_ARgvz8OQUJy3Xbx5Rw16Wxm3+1j5Q@mail.gmail.com>
 <20150315174646.GH9324@alap3.anarazel.de>
 <CAOR=d=2rC8dYr=tY7JQTNK+eszx2J1pRHuqYFHPbqxVDXiN1sQ@mail.gmail.com>
 <20150315224756.GE29732@awork2.anarazel.de>
 <550618C2.3030802@2ndquadrant.com> <55061BEB.5070209@sqlexec.com>
 <55061EC8.7030807@2ndquadrant.com> <55062128.7060804@sqlexec.com>
In-Reply-To: <55062128.7060804@sqlexec.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2015 20:00:40.1858 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR11MB0349
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 3/15/15 7:17 PM, michael@sqlexec.com wrote:
Please avoid top-posting.

> I agree with your counter argument about how high max_connections "can"
> cause problems, but max_connections may not part of the problem here.
> There's a bunch of "depends stuff" in there based on workload details, #
> cpus, RAM, etc.

Sure, but the big, huge danger with a very large max_connections is that 
you now have a large grenade with the pin pulled out. If *anything* 
happens to disturb the server and push the active connection count past 
the number of actual cores the box is going to fall over and not recover.

In contrast, if max_connections is <= the number of cores this is far 
less likely to happen. Each connection will get a CPU to run on, and as 
long as they're not all clamoring for the same locks the server will be 
making forward progress. Clients may have to wait in the pool for a free 
connection for some time, but once they get one their work will get done.

> I'm still waiting to find out how many CPUs on this DB server.  Did i
> miss it somewhere in the email thread below?

http://blog.musicbrainz.org/2015/03/15/postgres-troubles/ might show it 
somewhere...
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance