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

Поиск
Список
Период
Сортировка
От Stefan Kaltenbrunner
Тема pgbench cpu overhead (was Re: lazy vxid locks, v1)
Дата
Msg-id 4DF618CE.8000300@kaltenbrunner.cc
обсуждение исходный текст
Ответ на Re: lazy vxid locks, v1  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Ответы Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)  (Jeff Janes <jeff.janes@gmail.com>)
Re: pgbench cpu overhead (was Re: lazy vxid locks, v1)  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PATCH: CreateComments: use explicit indexing for ``values''
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY