From: Glyn Astill <glynastill@yahoo.co.uk>
To: david@lang.hm, Steve Clark <sclark@netwolves.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Joshua D. Drake <jd@commandprompt.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Linux: more cores = less concurrency.
Date: Tue, 12 Apr 2011 13:35:19 +0100 (BST)
Message-ID: <527122.4074.qm@web26005.mail.ukl.yahoo.com> (raw)
In-Reply-To: <4DA32DE3020000250003C68E@gw.wicourts.gov>
--- On Mon, 11/4/11, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
> Subject: Re: [PERFORM] Linux: more cores = less concurrency.
> To: david@lang.hm, "Steve Clark" <sclark@netwolves.com>, "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, "Glyn Astill" <glynastill@yahoo.co.uk>
> Cc: "Joshua D. Drake" <jd@commandprompt.com>, "Scott Marlowe" <scott.marlowe@gmail.com>, pgsql-performance@postgresql.org
> Date: Monday, 11 April, 2011, 22:35
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
> wrote:
>
> > I don't know why you were hitting the knee sooner than
> I've seen
> > in my benchmarks
>
> If you're compiling your own executable, you might try
> boosting
> LOG2_NUM_LOCK_PARTITIONS (defined in lwlocks.h) to 5 or
> 6. The
> current value of 4 means that there are 16 partitions to
> spread
> contention for the lightweight locks which protect the
> heavyweight
> locking, and this corresponds to your best throughput
> point. It
> might be instructive to see what happens when you tweak the
> number
> of partitions.
>
Tried tweeking LOG2_NUM_LOCK_PARTITIONS between 5 and 7. My results took a dive when I changed to 32 partitions, and improved as I increaced to 128, but appeared to be happiest at the default of 16.
> Also, if you can profile PostgreSQL at the sweet spot and
> again at a
> pessimal load, comparing the profiles should give good
> clues about
> the points of contention.
>
Results for the same machine on 8 and 32 cores are here:
http://www.8kb.co.uk/server_benchmarks/dblt_results.csv
Here's the sweet spot for 32 cores, and the 8 core equivalent:
http://www.8kb.co.uk/server_benchmarks/iostat-32cores_32Clients.txthttp://www.8kb.co.uk/server_benchmarks/vmstat-32cores_32Clients.txthttp://www.8kb.co.uk/server_benchmarks/iostat-8cores_32Clients.txthttp://www.8kb.co.uk/server_benchmarks/vmstat-8cores_32Clients.txt
... and at the pessimal load for 32 cores, and the 8 core equivalent:
http://www.8kb.co.uk/server_benchmarks/iostat-32cores_100Clients.txthttp://www.8kb.co.uk/server_benchmarks/vmstat-32cores_100Clients.txthttp://www.8kb.co.uk/server_benchmarks/iostat-8cores_100Clients.txthttp://www.8kb.co.uk/server_benchmarks/vmstat-8cores_100Clients.txt
vmstat shows double the context switches on 32 cores, could this be a factor? Is there anything else I'm missing there?
Cheers
Glyn
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: glynastill@yahoo.co.uk, sclark@netwolves.com, Kevin.Grittner@wicourts.gov, jd@commandprompt.com, scott.marlowe@gmail.com
Subject: Re: Linux: more cores = less concurrency.
In-Reply-To: <527122.4074.qm@web26005.mail.ukl.yahoo.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