On Mon, Feb 13, 2017 at 10:17 PM, Tomas Vondra <tomas.von...@2ndquadrant.com > wrote:
> On 02/13/2017 03:16 PM, Bernd Helmle wrote: > >> Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov: >> >>> Thus, I see reasons why in your tests absolute results are lower than >>> in my >>> previous tests. >>> 1. You use 28 physical cores while I was using 32 physical cores. >>> 2. You run tests in PowerVM while I was running test on bare metal. >>> PowerVM could have some overhead. >>> 3. I guess you run pgbench on the same machine. While in my tests >>> pgbench >>> was running on another node of IBM E880. >>> >>> >> Yeah, pgbench was running locally. Maybe we can get some resources to >> run them remotely. Interesting side note: If you run a second postgres >> instance with the same pgbench in parallel, you get nearly the same >> transaction throughput as a single instance. >> >> Short side note: >> >> If you run two Postgres instances concurrently with the same pgbench >> parameters, you get nearly the same transaction throughput for both >> instances each as when running against a single instance, e.g. >> >> > That strongly suggests you're hitting some kind of lock. It'd be good to > know which one. I see you're doing "pgbench -S" which also updates branches > and other tiny tables - it's possible the sessions are trying to update the > same row in those tiny tables. You're running with scale 1000, but with 100 > it's still possible thanks to the birthday paradox. > > Otherwise it might be interesting to look at sampling wait events, which > might tell us more about the locks. > +1 And you could try to use pg_wait_sampling <https://github.com/postgrespro/pg_wait_sampling> to sampling of wait events. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
