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
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'' |