Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group