pgbench cpu overhead (was Re: lazy vxid locks, v1)

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: pgbench cpu overhead (was Re: lazy vxid locks, v1)
Date: 2011-06-13 14:03:58
Message-ID: 4DF618CE.8000300@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-13 14:07:17 Re: Boolean operators without commutators vs. ALL/ANY
Previous Message Tom Lane 2011-06-13 14:03:49 Re: PATCH: CreateComments: use explicit indexing for ``values''