Re: pgbench intriguing results: better tps figures for larger scale factor

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: pgbench intriguing results: better tps figures for larger scale factor
Дата
Msg-id 51352445.4050305@2ndQuadrant.com
обсуждение исходный текст
Ответ на pgbench intriguing results: better tps figures for larger scale factor  (Costin Oproiu <costin.oproiu@gmail.com>)
Список pgsql-performance
On 2/26/13 4:45 PM, Costin Oproiu wrote:
> First, I've got no good explanation for this and it would be nice to
> have one. As far as I can understand this issue, the heaviest update
> traffic should be on the branches table and should affect all tests.

 From http://www.postgresql.org/docs/current/static/pgbench.html :

"For the default TPC-B-like test scenario, the initialization scale
factor (-s) should be at least as large as the largest number of clients
you intend to test (-c); else you'll mostly be measuring update
contention. There are only -s rows in the pgbench_branches table, and
every transaction wants to update one of them, so -c values in excess of
-s will undoubtedly result in lots of transactions blocked waiting for
other transactions."

I normally see peak TPS at a scale of around 100 on current generation
hardware, stuff in the 4 to 24 core range.  Nowadays there really is no
reason to consider running pgbench on a system with a smaller scale than
that.  I normally get a rough idea of things by running with scales 100,
250, 500, 1000, 2000.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


В списке pgsql-performance по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Schema obfuscator for performance question
Следующее
От: Steven Crandell
Дата:
Сообщение: Re: hardware upgrade, performance degrade?