re:Re: performance bottlenecks on lock transactionid

Поиск
Список
Период
Сортировка
От 王若楠
Тема re:Re: performance bottlenecks on lock transactionid
Дата
Msg-id tencent_25DF4C35A54D4A33B5206E53BF6D468BB208@qq.com
обсуждение исходный текст
Ответ на performance bottlenecks on lock transactionid  ("王若楠" <wrn@hljdx.net>)
Ответы Re: Re: performance bottlenecks on lock transactionid  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-performance

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.

------------------ 原始邮件 ------------------

发送时间: 2019年8月14日(星期三) 15:31
收件人: "王若楠" <wrn@hljdx.net>;"pgsql-performance" <pgsql-performance@lists.postgresql.org>;
主题: Re: performance bottlenecks on lock transactionid


王若楠 wrote:
> We used benchmarksql 4.1.0 to test the performance of PG12 beta TPCC.
> 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: performance bottlenecks on lock transactionid
Следующее
От: Daulat Ram
Дата:
Сообщение: RE: ORA-24345: A Truncation or null fetch error occurred -ora2pg