Re: pgbench tps drop from 5000 to 37 going from localhost to a server 13ms away
| От | Chris Withers |
|---|---|
| Тема | Re: pgbench tps drop from 5000 to 37 going from localhost to a server 13ms away |
| Дата | |
| Msg-id | 55B605C5.3020907@simplistix.co.uk обсуждение |
| Ответ на | Re: pgbench tps drop from 5000 to 37 going from localhost to a server 13ms away (Jeff Janes <jeff.janes@gmail.com>) |
| Ответы |
Re: pgbench tps drop from 5000 to 37 going from localhost
to a server 13ms away
|
| Список | pgsql-general |
On 24/07/2015 22:51, Jeff Janes wrote:
cheers,
Chris
Indeed it was!starting vacuum...end.transaction type: TPC-B (sort of)
scaling factor: 1This is your problem. There is only one row in the pgbench_branch table, and every transaction has to update that one row. This is inherently a seriaized event.
With a scale of 1000, everything except the END took roughly the latency time. Interestingly, the END still seems to take more, when threads/clients are really ramped up (100 vs 8). Why would that be?One solution is to just use a large scale on the benchmark so that they upate random pgbench_branch rows, rather than all updating the same row:pgbench -i -s50
How would you restructure the sql so as the make that happen?Alternatively, you could write a custom file so that all 7 commands are sent down in one packet.
cheers,
Chris
В списке pgsql-general по дате отправления: