re:Re: performance bottlenecks on lock transactionid

hello,Laurenz Albe

Yes, pg_locks is only an item that does not get a lock in the view. The test data is 300 warehouses connections, and the CPU is only about 60%. I think the lock becomes a performance bottleneck at this time. I want to find a way to reduce the lock waiting and improve the performance.

------------------ 原始邮件 ------------------
发件人:&nbsp;"Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at&gt;;
发送时间:&nbsp;2019年8月14日(星期三) 15:31
收件人:&nbsp;"王若楠" <wrn(at)hljdx(dot)net&gt;;"pgsql-performance" <pgsql-performance(at)lists(dot)postgresql(dot)org&gt;;
主题:&nbsp;Re: performance bottlenecks on lock transactionid

王若楠 wrote:
&gt; We used benchmarksql 4.1.0 to test the performance of PG12 beta TPCC.
&gt; We found performance bottlenecks on lock transactionid.

You included an attachment with results from the "pg_locks" view
where "granted" is FALSE for all entries.

I'll assume that these are not *all* the entries in the view, right?

Since the locks are waiting for different transaction IDs, I'd
assume that this is just a case of contention: many transactions are
trying to modify the same rows concurrently.

This is to be expected.
Perhaps your benchmark is running with too many connections on
too few table rows?

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com