Re: Performance decrease after upgrade to 9.6.1

Hi Tom!

Thanks for the answer.

This is just one of the benchmark that we run, we test with fewer clients and much more time, but you're right about de scale-factor, we didn't realize about that.

We are going to test using your recomendations.

Thanks!

________________________________
De: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Enviado: martes, 15 de noviembre de 2016 19:35:03
Para: Gabriela Serventi
Cc: pgsql-performance(at)postgresql(dot)org
Asunto: Re: [PERFORM] Performance decrease after upgrade to 9.6.1

Gabriela Serventi <gabrielaserventi(at)hotmail(dot)com> writes:
> $ pgbench -l -c 100 -T 30 pgbench
> starting vacuum...end.
> transaction type: <builtin: TPC-B (sort of)>
> scaling factor: 1
> query mode: simple
> number of clients: 100
> number of threads: 1
> duration: 30 s
> number of transactions actually processed: 27428
> latency average = 110.104 ms
> tps = 908.234296 (including connections establishing)
> tps = 908.278187 (excluding connections establishing)

That's not a tremendously exciting benchmark case, for a number of
reasons:

* 100 sessions in a scale-factor-1 database are all going to be fighting
over updating the single row in the pgbench_branches table.

* 100 sessions driven by a single pgbench thread are probably going to be
bottlenecked by that thread, not by the server.

* 100 sessions on a machine with only 2 cores is going to be all about
process-swap contention anyhow.

My first thought about why the difference from 8.4 to 9.6 is that pgbench
has grown a lot more measurement apparatus since then (for example, the
transaction latency numbers, which weren't there at all in 8.4). You
might try testing 9.6 server with 8.4 pgbench and vice versa to tease out
how much of this is actually on pgbench changes not the server. But in
the end, what you're measuring here is mostly contention, and you'd need
to alter the test parameters to make it not so. The "Good Practices"
section at the bottom of the pgbench reference page has some tips about
that.

regards, tom lane