Message-ID: <5505891B.6060800@2ndquadrant.com>
Date: Sun, 15 Mar 2015 14:28:59 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Organization: 2ndQuadrant
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 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>
 <CAB6McgXxZdD6yuYRLg4tgDdhqzXKLs63aV+S_nOfZ9arSXUAhA@mail.gmail.com>
 <9E71CCBE-4CDF-482E-878D-6C16027B6283@musicbrainz.org>
In-Reply-To: <9E71CCBE-4CDF-482E-878D-6C16027B6283@musicbrainz.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 15.3.2015 13:07, Robert Kaye wrote:
>
>> If the load problem really is being caused by swapping when things
>> really shouldn't be swapping, it could be a matter of adjusting your
>> swappiness - what does cat /proc/sys/vm/swappiness show on your server?
> 
> 0 
> 
> We adjusted that too, but no effect.
> 
> (I’ve updated the blog post with these two comments)

IMHO setting swappiness to 0 is way too aggressive. Just set it to
something like 10 - 20, that works better in my experience.


>> There are other linux memory management things that can cause
>> postgres and the server running it to throw fits like THP and zone
>> reclaim. I don't have enough info about your system to say they are
>> the cause either, but check out the many postings here and other
>> places on the detrimental effect that those settings *can* have.
>> That would at least give you another angle to investigate.
> 
> If there are specific things you’d like to know, I’ve be happy to be a
> human proxy. :)

I'd start with vm.* configuration, so the output from this:

# sysctl -a | grep '^vm.*'

and possibly /proc/meminfo. I'm especially interested in the overcommit
settings, because per the free output you provided there's ~16GB of free
RAM.

BTW what amounts of data are we talking about? How large is the database
and how large is the active set?


I also noticed you use kernel 3.2 - that's not the best kernel version
for PostgreSQL - see [1] or [2] for example.

[1]
https://medium.com/postgresql-talk/benchmarking-postgresql-with-different-linux-kernel-versions-on-ubuntu-lts-e61d57b70dd4

[2]
http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html


-- 
Tomas Vondra                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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