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

help / color / mirror / Atom feed
From: Shaun Thomas <sthomas@optionshouse.com>
To: Віталій Тимчишин <tivv00@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Tons of free RAM. Can't make it go away.
Date: Mon, 29 Oct 2012 11:17:15 -0500
Message-ID: <508EAC0B.7010609@optionshouse.com> (raw)
In-Reply-To: <CABWW-d37ut8uWFDvLrv9Pa9wwiX2425F3bn4cVJXwt-jj2pJRg@mail.gmail.com>
References: <508583E4.8080102@optionshouse.com>
	<CABWW-d37ut8uWFDvLrv9Pa9wwiX2425F3bn4cVJXwt-jj2pJRg@mail.gmail.com>

On 10/27/2012 10:49 PM, Віталій Тимчишин wrote:

> It can be that some query(s) use a lot of work mem, either because of
> high work_mem setting or because of planner error. In this case the
> moment query runs it will need memory that will later be returned and
> become free. Usually this can be seen as active memory spike with a lot
> of free memory after.

Yeah, I had briefly considered that. But our work-mem is only 16MB, and 
even a giant query would have trouble allocating 10+GB with that size of 
work-mem buckets.

That's why I later listed the numa info. In our case, processor 0 is 
heavily unbalanced with its memory accesses compared to processor 1. I 
think the theory that we didn't start with interleave put an 8GB (our 
shared_buffers) segment all on processor 0, which unbalanced a lot of 
other stuff.

Of course, that leaves 4-6GB unaccounted for. And numactl still shows a 
heavy preference for freeing memory from proc 0. It seems to only do it 
on this node, so we're going to switch nodes soon and see if the problem 
reappears. We may have to perform a node hardware audit if this persists.

Thanks for your input, though. :)

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email




view thread (15+ messages)

Message-ID: <508EAC0B.7010609@optionshouse.com>
Permalink:  ../508EAC0B.7010609@optionshouse.com/
Also on:    postgresql.org/message-id/508EAC0B.7010609@optionshouse.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: sthomas@optionshouse.com, tivv00@gmail.com
  Subject: Re: Tons of free RAM. Can't make it go away.
  In-Reply-To: <508EAC0B.7010609@optionshouse.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