From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Christian Gough <brukshut@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Postgresql Host Swapping Hard With Abundant Free Memory
Date: Wed, 22 Apr 2015 18:33:11 -0500
Message-ID: <55382FB7.7050204@BlueTreble.com> (raw)
In-Reply-To: <A9721354-B72F-4698-A616-1894174C2A2B@gmail.com>
References: <A9721354-B72F-4698-A616-1894174C2A2B@gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 4/17/15 1:25 PM, Christian Gough wrote:
> Here are our competing theories of why we are swapping as much as 10-15GB with 6GB-10GB of free memory:
How are you determining that you're swapping?
How are you measuring 'free memory'?
> 1.) maintenance_work_mem and work_mem are set too high causing postgres to allocate too much memory
There's not much that uses maintenance_work_mem. (AUTO)VACUUM, CREATE
INDEX... I think that's it. Also, I believe it's internally limited to 1G.
As for work_mem, it's hard to say. As your math shows, if *every*
connection suddenly allocated a full work_mem then you'd be in trouble.
But that would be a pretty extreme situation. Even though a backend can
actually have multiple work_mem consuming operations in use at once, so
it could theoretically use several times work_mem, in reality I think
it's very rare for every backend to use even a fraction of work_mem.
But, there's no need to theorize here; work_mem will be reported as
allocated to each backend and will not be considered free memory by the OS.
> 2.) The 6GB - 10GB of free memory observed during swapping is postgresql's shared buffer
If anything, I'd expect the OS to avoid swapping a shared memory segment
(if not flat-out refuse to swap it).
Shared memory certainly shouldn't be counted as free either. The only
tricky bit here is many OSes will report shared memory as part of the
memory footprint *for each backend*. So if you have 170 backends and 8GB
shared buffers, it could look like you're using 13.6TB of memory (which
you're obviously not).
> 3.) Linux filesystem caching is tuned incorrectly, maybe SSD related?
Possibly, though I don't think it'd be SSD related...
> 4.) This is a NUMA related issue similar to the Mysql Swap Insanity issue:
Since you have that turned off, I don't think so.
--
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
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, brukshut@gmail.com
Subject: Re: Postgresql Host Swapping Hard With Abundant Free Memory
In-Reply-To: <55382FB7.7050204@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