Re: multi-threaded pgbench

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Josh Williams <joshwilliams(at)ij(dot)net>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multi-threaded pgbench
Date: 2009-07-30 00:35:36
Message-ID: alpine.GSO.2.01.0907291918380.19638@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This patch is wrapping up nicely. I re-tested against the updated
pgbench-mt_20090724 and now I get similar results whether or not
--enable-thread-safety is enabled on Linux, so that problem is gone.
Josh's successful Windows tests along with finding the bug he attached a
patch to is also encouraging.

I re-ran my performance tests with the same basic setup (16 core system,
database scale=10, read-only tests) but this time increased shared_buffers
to 256MB just to see if results popped up significantly (they didn't).

Here's a comparison of the original pgbench select-only TPS against the
new version using 1 thread:

clients
threads 16 32 64 128
none 91763 69707 68465 63730
1 90797 70117 66324 63626

I ran these a few times and those are basically the same result. If
there's a regression using 1 threads instead of 1 process, which I thought
I was seeing at one point with j=1/c=128, under closer investigation it
would have to be much smaller than the run to run variation of pgbench
because it vanished when I collected many runs of data.

Running the new pgbench with thread safety turned on:

clients
threads 16 32 64 128
1 89503 67849 67120 63499
2 97883 91888 87556 84430
4 95319 96409 90445 83569
8 96002 95411 88988 82383
16 103798 95056 87701 82253
32 X 95869 88253 82253

Running it without thread safety turned on so it uses processes instead
(this is the case I couldn't report on before):

clients
threads 16 32 64 128
1 89706 68702 64545 62770
2 99224 91677 88812 82442
4 96124 96552 90245 83311
8 97066 96000 89149 83266
16 103276 96088 88276 82652
32 X 97405 90082 83672

Those two tables are also identical relative to the run to run pgbench
noise.

This looks ready for a committer review to me, I'm happy that the patch
performs as expected and it seems to work across two platforms.

To step back for a second, I'm testing a fairly optimistic situation--the
standard RHEL 2.6.18 kernel which doesn't have any major issues here--and
I see a decent sized speedup (>30%) in the worst case. I've reported
before that running pgbench on newer Linux kernels (>=2.6.23) is horribly
slow, and sure enough the original results kicking off this thread showed
the same thing: only 11600 TPS on a modern 8 core system. That's less
than 1/4 what that server is capable of, and this patch allows working
around that issue nicely. pgbench not scaling up really a much worse
problem than my test results suggest.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-07-30 00:42:53 Re: improvements for dict_xsyn extended synonym dictionary - RRR
Previous Message Robert Haas 2009-07-30 00:26:54 Re: RFD: Don't force plpgsql IN parameters to constant