Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M52856=pgsql-performance-ar@postgresql.org>)
 id 1YXKhI-0000Ub-V5
 for pgsql-performance@arkaria.postgresql.org; Mon, 16 Mar 2015 02:24:05 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M52856=pgsql-performance-ar@postgresql.org>)
 id 1YXKhI-0000Ex-4F
 for pgsql-performance@arkaria.postgresql.org; Mon, 16 Mar 2015 02:24:04 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <rox@tara-lu.com>) id 1YXKhF-0000AL-QQ
 for pgsql-performance@postgresql.org; Mon, 16 Mar 2015 02:24:01 +0000
Received: from mail6.webfaction.com ([74.55.86.74] helo=smtp.webfaction.com)
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <rox@tara-lu.com>) id 1YXKhB-0003dK-44
 for pgsql-performance@postgresql.org; Mon, 16 Mar 2015 02:24:00 +0000
Received: from [192.168.1.114] (pool-173-79-115-80.washdc.fios.verizon.net
 [173.79.115.80])
 by smtp.webfaction.com (Postfix) with ESMTP id B1C3D20EA9C4
 for <pgsql-performance@postgresql.org>; Mon, 16 Mar 2015 02:23:54 +0000 (UTC)
Message-ID: <55063EBC.5020405@tara-lu.com>
Date: Sun, 15 Mar 2015 22:23:56 -0400
From: Roxanne Reid-Bennett <rox@tara-lu.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: MusicBrainz postgres performance issues
References: <B008F2EE-45D7-4535-9163-56A8CDCA553C@musicbrainz.org>
In-Reply-To: <B008F2EE-45D7-4535-9163-56A8CDCA553C@musicbrainz.org>
Content-Type: multipart/alternative;
 boundary="------------010805010009090505090106"
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

This is a multi-part message in MIME format.
--------------010805010009090505090106
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 3/15/2015 6:54 AM, Robert Kaye wrote:
> Hi!
>
> We at MusicBrainz have been having trouble with our Postgres install 
> for the past few days. I’ve collected all the relevant information here:
>
> http://blog.musicbrainz.org/2015/03/15/postgres-troubles/
>
> If anyone could provide tips, suggestions or other relevant advice for 
> what to poke at next, we would love it.
Robert,

Wow - You've engaged the wizards indeed.

I haven't heard or seen anything that would answer my *second* question 
if faced with this (my first would have been "what changed")....

What is the database actually trying to do when it spikes?  e.g. what 
queries are running ?
Is there any pattern in the specific activity (exactly the same query, 
or same query different data, or even just same tables, and/or same 
users, same apps) when it spikes?

I know from experience that well behaved queries can stop being well 
behaved if underlying data changes

and for the experts... what would a corrupt index do to memory usage?

Roxanne

--------------010805010009090505090106
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 3/15/2015 6:54 AM, Robert Kaye
      wrote:<br>
    </div>
    <blockquote
      cite="mid:B008F2EE-45D7-4535-9163-56A8CDCA553C@musicbrainz.org"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Hi!
      <div class=""><br class="">
      </div>
      <div class="">We at MusicBrainz have been having trouble with our
        Postgres install for the past few days. I’ve collected all the
        relevant information here:</div>
      <div class=""><br class="">
      </div>
      <div class="">  <a moz-do-not-send="true"
          href="http://blog.musicbrainz.org/2015/03/15/postgres-troubles/"
          class="">http://blog.musicbrainz.org/2015/03/15/postgres-troubles/</a></div>
      <div class=""><br class="">
      </div>
      <div class="">If anyone could provide tips, suggestions or other
        relevant advice for what to poke at next, we would love it.</div>
    </blockquote>
    Robert,<br>
    <br>
    Wow - You've engaged the wizards indeed.<br>
    <br>
    I haven't heard or seen anything that would answer my *second*
    question if faced with this (my first would have been "what
    changed")....<br>
    <br>
    What is the database actually trying to do when it spikes?  e.g.
    what queries are running ?<br>
    Is there any pattern in the specific activity (exactly the same
    query, or same query different data, or even just same tables,
    and/or same users, same apps) when it spikes?<br>
    <br>
    I know from experience that well behaved queries can stop being well
    behaved if underlying data changes <br>
    <br>
    and for the experts... what would a corrupt index do to memory
    usage?<br>
    <br>
    Roxanne<br>
  </body>
</html>

--------------010805010009090505090106--