pgbench cpu overhead (was Re: lazy vxid locks, v1) - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject pgbench cpu overhead (was Re: lazy vxid locks, v1)
Date
Msg-id 4DF618CE.8000300@kaltenbrunner.cc
Whole thread Raw
In response to Re: lazy vxid locks, v1  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Responses Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)
Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)
List pgsql-hackers
On 06/13/2011 01:55 PM, Stefan Kaltenbrunner wrote:

[...]

> all those tests are done with pgbench running on the same box - which
> has a noticable impact on the results because pgbench is using ~1 core
> per 8 cores of the backend tested in cpu resoures - though I don't think
> it causes any changes in the results that would show the performance
> behaviour in a different light.

actuall testing against sysbench with the very same workload shows the
following performance behaviour:

with 40 threads(aka the peak performance point):

pgbench:    223308 tps
sysbench:     311584 tps

with 160 threads (backend contention dominated):

pgbench:    57075
sysbench:    43437


so it seems that sysbench is actually significantly less overhead than
pgbench and the lower throughput at the higher conncurency seems to be
cause by sysbench being able to stress the backend even more than
pgbench can.


for those curious - the profile for pgbench looks like:

samples  %        symbol name
29378    41.9087  doCustom
17502    24.9672  threadRun
7629     10.8830  pg_strcasecmp
5871      8.3752  compareVariables
2568      3.6633  getVariable
2167      3.0913  putVariable
2065      2.9458  replaceVariable
1971      2.8117  parseVariable
534       0.7618  xstrdup
278       0.3966  xrealloc
137       0.1954  xmalloc



Stefan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH: CreateComments: use explicit indexing for ``values''
Next
From: Robert Haas
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY