pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Gunnar \"Nick\" Bluth <gunnar.bluth@pro-open.de>
To: Petr Praus <petr@praus.net>
Cc: Marcos Ortiz <mlortiz@uci.cu>
Cc: pgsql-performance@postgresql.org
Subject: Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
Date: Sun, 04 Nov 2012 09:48:11 +0100
Message-ID: <50962BCB.7020709@pro-open.de> (raw)
In-Reply-To: <CACezXZ-NBmEd-Ur8TKvi2fhJkLAC=7w4y93ZPPzoFa1rZH+nmg@mail.gmail.com>
References: <CACezXZ_w7HbqSxZ=5SJH=kxb4nBDNbpDejttSaU6EC1AeO4PYg@mail.gmail.com>
	<CACezXZ_UYbzvNEP_V6-bsyzGij-kJdeNz04-o=kbMXmcLMHnqw@mail.gmail.com>
	<5092DE42.5060206@uci.cu>
	<509304DC.1090809@pro-open.de>
	<CACezXZ-p1UK0K4EJH8b+EBuiD5HY0vNaQvxrnMcjwvjf9cb+oQ@mail.gmail.com>
	<5094F280.6010606@pro-open.de>
	<CACezXZ9SV58CbFM3-MpKGm1z-J0Ho1zERMUBuLH6QhC7RJ5T8Q@mail.gmail.com>
	<50954FAF.3060905@pro-open.de>
	<CACezXZ-NBmEd-Ur8TKvi2fhJkLAC=7w4y93ZPPzoFa1rZH+nmg@mail.gmail.com>

Am 03.11.2012 18:19, schrieb Petr Praus:
> On 3 November 2012 12:09, Gunnar "Nick" Bluth 
> <gunnar.bluth@pro-open.de <mailto:gunnar.bluth@pro-open.de>> wrote:
>
>     Am 03.11.2012 16:20, schrieb Petr Praus:
>>
>>         Your CPUs are indeed pretty oldschool. FSB based, IIRC, not
>>         NUMA. A process migration would be even more expensive there.
>>
>
>     Ok, I've actually looked these up now... at the time these were
>     current, I was in the lucky situation to only deal with Opterons.
>     And actually, with these CPUs it is pretty possible that Scott
>     Marlowe's hint (check vm.zone_reclaim_mode) was pointing in the
>     right direction. Did you check that?
>
>
> I did check that, it's zero. I responded to his message, but my 
> messages to the mailing list are getting delayed by ~24 hours because 
> somebody has to always bless them.
>
>
>
>>         Yes, same behaviour. I let the shared_buffers be the default
>>         (which is 8MB). With work_mem 1MB the query runs fast, with
>>         96MB it runs slow (same times as before). It really seems
>>         that the culprit is work_mem.
>>
>>
>
>     Well, I'm pretty sure that having more work_mem is a good thing
>     (tm) normally ;-)
>
>
> Well, that's what I always thought too! :-)
>
So, to sum this up (and make someone more competent bite on it maybe 
;-), on your SMP, FSB, "fake-multicore" system all "hash"-related works 
that potentially switch to different implementations internally (but 
w/out telling us so) when given more work_mem are slower.

I'm pretty sure you're hitting some subtle, memory-access-related 
cornercase here.

The L2 cache of your X7350 CPUs is 2MB, could you run the tests with, 
say, 1, 2, 4 and 8MB of work_mem and post the results?

-- 
Gunnar "Nick" Bluth
RHCE/SCLA

Mobil   +49 172 8853339
Email: gunnar.bluth@pro-open.de
__________________________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX.  Ten years later
they are choosing Windows over UNIX.  What part of that message aren't you
getting? - Tom Payne

view thread (27+ messages)  latest in thread

Message-ID: <50962BCB.7020709@pro-open.de>
Permalink:  ../50962BCB.7020709@pro-open.de/
Also on:    postgresql.org/message-id/50962BCB.7020709@pro-open.de

 · 

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: gunnar.bluth@pro-open.de, petr@praus.net, mlortiz@uci.cu
  Subject: Re: Re: Increasing work_mem and shared_buffers on Postgres 9.2 significantly slows down queries
  In-Reply-To: <50962BCB.7020709@pro-open.de>

* 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