Re: SubtransControlLock and performance problems

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: SubtransControlLock and performance problems
Date: 2020-02-17 09:53:21
Message-ID: eec0413432096c46c96580a7776f13a6f27a9858.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Lars Aksel Opsahl wrote:
> What happens is that after some minutes the CPU can fall to maybe 20% usage and most of
> the threads are blocked by SubtransControlLock, and when the number SubtransControlLock
> goes down the CPU load increases again. The jobs usually goes through without any errors,
> but it takes to long time because of the SubtransControlLock blocks.

That's typically a sign that you are using more than 64 subtransactions per transaction.

That could either be SAVEPOINT SQL statements or PL/pgSQL code with blocks
containing the EXCEPTION clause.

The data structure in shared memory that holds information for each session
can cache 64 subtransactions, beyond that it has to access "pg_subtrans" to get
the required information, which leads to contention.

Often the problem is caused by a misguided attempt to wrape every single
statement in a subtransaction to emulate the behavior of other database
systems, for example with the "autosave = always" option of the JDBC driver.

The solution is to use fewer subtransactions per transaction.

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Lars Aksel Opsahl 2020-02-17 15:03:56 Re: SubtransControlLock and performance problems
Previous Message Tom Lane 2020-02-17 01:09:00 Re: Partial index creation always scans the entire table