re:Re: performance bottlenecks on lock transactionid

"王若楠" <[email protected]> Wed, 14 Aug 2019 15:57:04 +0800

Newsgroups	gmane.comp.db.postgresql.performance
Message-ID	<[email protected]>

hello,Laurenz&nbsp;Albe

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

------------------ 原始邮件 ------------------
发件人:&nbsp;"Laurenz Albe" <[email protected]&gt;;
发送时间:&nbsp;2019年8月14日(星期三) 15:31
收件人:&nbsp;"王若楠" <[email protected]&gt;;"pgsql-performance" <[email protected]&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