pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Carey <scott@richrelevance.com>
To: Glyn Astill <glynastill@yahoo.co.uk>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Greg Smith <greg@2ndquadrant.com>
Cc: david@lang.hm <david@lang.hm>
Cc: Steve Clark <sclark@netwolves.com>
Cc: Joshua D. Drake <jd@commandprompt.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Linux: more cores = less concurrency.
Date: Wed, 13 Apr 2011 09:33:26 -0700
Message-ID: <C9CB1C26.30643%scott@richrelevance.com> (raw)
In-Reply-To: <188622.2398.qm@web26002.mail.ukl.yahoo.com>

If postgres is memory bandwidth constrained, what can be done to reduce
its bandwidth use?

Huge Pages could help some, by reducing page table lookups and making
overall access more efficient.
Compressed pages (speedy / lzo) in memory can help trade CPU cycles for
memory usage for certain memory segments/pages -- this could potentially
save a lot of I/O too if more pages fit in RAM as a result, and also make
caches more effective.

As I've noted before, the optimizer inappropriately choses the larger side
of a join to hash instead of the smaller one in many cases on hash joins,
which is less cache efficient.
Dual-pivot quicksort is more cache firendly than Postgres' single pivit
one and uses less memory bandwidth on average (fewer swaps, but the same
number of compares).



On 4/13/11 2:48 AM, "Glyn Astill" <glynastill@yahoo.co.uk> wrote:

>--- On Tue, 12/4/11, Greg Smith <greg@2ndquadrant.com> wrote:
>
>>
>> 
>
>Thanks Greg.  I've been through that post, but unfortunately there's no
>settings that make a difference.
>
>However upon further investigation and looking at the manual for the R910
>here
>
>http://support.dell.com/support/edocs/systems/per910/en/HOM/HTML/install.h
>tm#wp1266264
>
>I've discovered we only have 4 of the 8 memory risers, and the manual
>states that in this configuration we are running in "Power Optimized"
>mode, rather than "Performance Optimized".
>
>We've got two of these machines, so I've just pulled all the risers from
>one system, removed half the memory as indicated by that document from
>Dell above, and now I'm seeing almost double the throughput.
>
>
>
>-- 
>Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance




view thread (51+ messages)  latest in thread

Message-ID: <C9CB1C26.30643%scott@richrelevance.com>
Permalink:  ../C9CB1C26.30643%25scott@richrelevance.com/
Also on:    postgresql.org/message-id/C9CB1C26.30643%scott@richrelevance.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: scott@richrelevance.com, glynastill@yahoo.co.uk, Kevin.Grittner@wicourts.gov, greg@2ndquadrant.com, david@lang.hm, sclark@netwolves.com, jd@commandprompt.com, scott.marlowe@gmail.com
  Subject: Re: Linux: more cores = less concurrency.
  In-Reply-To: <C9CB1C26.30643%scott@richrelevance.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