Re: pgbench internal contention

On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> If I'm reading the code right, it only modifies __libc_drand48_data on
> first call, so as long as we called erand48() at least once before
> spawning the child threads, it would probably work.  That seems pretty
> fragile in the face of the fact that they explicitly state that
> they're modifying the global random generator state and that you
> should use erand48_r() if you want reentrant behavior.  So I think if
> we're going to go the erand48() route we probably ought to force
> pgbench to always use our version rather than any OS-supplied version.

Attached is a try at that approach.  Performance benefits are similar
to before.  Same test case as in my OP on this thread, alternating
runs without and with this patch:

tps = 199133.418419 (including connections establishing)
real    5m0.017s
user    23m42.170s
sys    18m46.270s

tps = 226202.289151 (including connections establishing)
real    5m0.018s
user    22m7.520s
sys    9m54.570s

tps = 191144.247489 (including connections establishing)
real    5m0.025s
user    23m35.200s
sys    17m19.070s

tps = 226353.187955 (including connections establishing)
real    5m0.017s
user    21m42.300s
sys    10m9.820s

tps = 189602.248908 (including connections establishing)
real    5m0.044s
user    23m24.060s
sys    17m1.050s

tps = 224521.459164 (including connections establishing)
real    5m0.017s
user    22m9.620s
sys    10m22.590s

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company