Re: pgbench results arent accurate

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench results arent accurate
Date: 2018-12-18 03:10:50
Message-ID: 9cccf498-527f-cd7b-8601-853d10b7990c@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi, I can see two issues making you get variable results:

1/ Number of clients > scale factor

Using -c16 and -s 6 means you are largely benchmarking lock contention
for a row in the branches table (it has 6 rows in your case). So
randomness in *which* rows each client tries to lock will make for
unwanted variation.

2/ Short run times

That 1st run is 5s duration. This will be massively influenced by the
above point about randomness for locking a branches row.

I'd recommend:

- always run at least -T600

- use -s of at least 1.5x your largest -c setting (I usually use -s 100
for testing 1-32 clients).

regards

Mark

On 17/12/18 12:58 AM, Mariel Cherkassky wrote:
> As Greg suggested, update you all that each vm has its own dedicated
> esx. Every esx has it`s own local disks.
> I run it one time on two different servers that has the same hardware
> and same postgresql db (version and conf). The results :
> pgbench -i -s 6  pgbench -p 5432 -U postgres
>  pgbench -c 16 -j 4 -T 5 -U postgres pgbench
> MACHINE 1
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 6
> query mode: simple
> number of clients: 16
> number of threads: 4
> duration: 5 s
> number of transactions actually processed: 669
> latency average = 122.633 ms
> tps = 130.470828 (including connections establishing)
> tps = 130.620286 (excluding connections establishing)
>
> MACHINE 2
>
> pgbench -c 16 -j 4 -T 600 -U postgres -p 5433 pgbench
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 6
> query mode: simple
> number of clients: 16
> number of threads: 4
> duration: 600 s
> number of transactions actually processed: 2393723
> latency average = 4.011 ms
> tps = 3989.437514 (including connections establishing)
> tps = 3989.473036 (excluding connections establishing)
>
> any idea what can cause such a difference ? Both of the machines have
> 20core and 65GB of ram.
>
> ‫בתאריך יום ה׳, 13 בדצמ׳ 2018 ב-15:54 מאת ‪Mariel Cherkassky‬‏
> <‪mariel(dot)cherkassky(at)gmail(dot)com <mailto:mariel(dot)cherkassky(at)gmail(dot)com>‬‏>:‬
>
> Ok, I'll do that.  Thanks .
>
> ‫בתאריך יום ה׳, 13 בדצמ׳ 2018 ב-15:54 מאת ‪Greg Clough‬‏
> <‪Greg(dot)Clough(at)ihsmarkit(dot)com <mailto:Greg(dot)Clough(at)ihsmarkit(dot)com>‬‏>:‬
>
> Hmmm... sounds like you’ve got most of it covered.  It may be
> a good idea to send that last message back to the list, as
> maybe others will have better ideas.
>
> Greg.
>
> *From:* Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com
> <mailto:mariel(dot)cherkassky(at)gmail(dot)com>>
> *Sent:* Thursday, December 13, 2018 1:45 PM
> *To:* Greg Clough <Greg(dot)Clough(at)ihsmarkit(dot)com
> <mailto:Greg(dot)Clough(at)ihsmarkit(dot)com>>
> *Subject:* Re: pgbench results arent accurate
>
> Both of the machines are the only vms in a dedicated esx for
> each one. Each esx has local disks.
>
> On Thu, Dec 13, 2018, 3:05 PM Greg Clough
> <Greg(dot)Clough(at)ihsmarkit(dot)com <mailto:Greg(dot)Clough(at)ihsmarkit(dot)com>
> wrote:
>
> > I installed a new postgres 9.6 on both of my machines.
>
> Where is your storage?  Is it local, or on a SAN?  A SAN
> will definitely have a cache, so possibly there is another
> layer of cache that you’re not accounting for.
>
> Greg Clough.
>
> ------------------------------------------------------------------------
>
>
> This e-mail, including accompanying communications and
> attachments, is strictly confidential and only for the
> intended recipient. Any retention, use or disclosure not
> expressly authorised by IHSMarkit is prohibited. This
> email is subject to all waivers and other terms at the
> following link:
> https://ihsmarkit.com/Legal/EmailDisclaimer.html
>
> Please visit www.ihsmarkit.com/about/contact-us.html
> <http://www.ihsmarkit.com/about/contact-us.html> for
> contact information on our offices worldwide.
>
>
> ------------------------------------------------------------------------
>
> This e-mail, including accompanying communications and
> attachments, is strictly confidential and only for the
> intended recipient. Any retention, use or disclosure not
> expressly authorised by IHSMarkit is prohibited. This email is
> subject to all waivers and other terms at the following link:
> https://ihsmarkit.com/Legal/EmailDisclaimer.html
>
> Please visit www.ihsmarkit.com/about/contact-us.html
> <http://www.ihsmarkit.com/about/contact-us.html> for contact
> information on our offices worldwide.
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2018-12-18 16:40:04 Re: Why Postgres doesn't use TID scan?
Previous Message Vladimir Ryabtsev 2018-12-18 02:40:49 Re: Why Postgres doesn't use TID scan?