Re: FW: huge SubtransSLRU and SubtransBuffer wait_event - Mailing list pgsql-performance

From James Pang
Subject Re: FW: huge SubtransSLRU and SubtransBuffer wait_event
Date
Msg-id CAHgTRfcfoiDu3KG841=PrHhBupPZptuSv1mwaEE_wdkU8SF9bQ@mail.gmail.com
Whole thread Raw
In response to huge SubtransSLRU and SubtransBuffer wait_event  ("James Pang (chaolpan)" <chaolpan@cisco.com>)
List pgsql-performance

 

 From this link, looks like "onfigurable buffer pool and partitioning the SLRU lock" is one the plan,  maybe from v18,19 version,  https://www.postgresql.org/message-id/202402221843.ibzvpndbacbi@alvherre.pgsql


    James  

From: James Pang (chaolpan)
Sent: Tuesday, February 6, 2024 2:59 PM
To: Nikolay Samokhvalov <samokhvalov@gmail.com>; Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-performance@lists.postgresql.org
Subject: RE: huge SubtransSLRU and SubtransBuffer wait_event

 

   We finally identified the cause, a pl/pgsql procedure  proc1 (for 1…5000 loop  call proc2()); proc2 (begin ..exception..end); at the same time, more than 200 sessions coming in milliseconds and do same query during the “call proc1 long running transaction”.  The code change and cutdown the parallel sessions count doing same query at the same time help a lot.

   

   Thanks all.

 

James

 

From: Nikolay Samokhvalov <samokhvalov@gmail.com>
Sent: Friday, February 2, 2024 6:04 PM
To: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-performance@lists.postgresql.org
Subject: Re: huge SubtransSLRU and SubtransBuffer wait_event

 

 

 

On Thu, Feb 1, 2024 at 04:42 Laurenz Albe <laurenz.albe@cybertec.at> wrote:

Today, the only feasible solution is not to create more than 64 subtransactions
(savepoints or PL/pgSQL EXCEPTION clauses) per transaction.

 

Sometimes, a single subtransaction is enough to experience a bad SubtransSLRU spike: 

 

I think 64+ nesting level is quite rare, but this kind of problem that hits you when you have high XID growth (lots of writes) + long-running transaction is quite easy to bump into. Or this case involving MultiXactIDs: 

 

Nik

pgsql-performance by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: sql statement not using all primary key values and poor performance
Next
From: Chema
Date:
Subject: Optimizing count(), but Explain estimates wildly off