pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: michael@sqlexec.com <michael@sqlexec.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: MusicBrainz postgres performance issues
Date: Mon, 16 Mar 2015 15:01:04 -0500
Message-ID: <55073680.7090104@BlueTreble.com> (raw)
In-Reply-To: <55062128.7060804@sqlexec.com>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

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



view thread (41+ messages)  latest in thread

Message-ID: <55073680.7090104@BlueTreble.com>
Permalink:  ../55073680.7090104@BlueTreble.com/
Also on:    postgresql.org/message-id/55073680.7090104@BlueTreble.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: Jim.Nasby@BlueTreble.com, michael@sqlexec.com, tomas.vondra@2ndquadrant.com
  Subject: Re: MusicBrainz postgres performance issues
  In-Reply-To: <55073680.7090104@BlueTreble.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox