Re: BUG #18141: sorry, too many clients error occurring very frequently

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, ravi(dot)s(dot)agrawal23(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18141: sorry, too many clients error occurring very frequently
Date: 2023-10-01 18:27:05
Message-ID: ac88d4c9-692c-07ff-03de-fb3f524d5b0f@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 10/1/23 14:09, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> Maybe, maybe not. I have seen two other cases that are similar. One was
>> an upgrade from 12.8 to 12.12 and the other an upgrade from 13.4 to 13.8.
>
>> I checked and 12.8 was stamped is the same date as 13.4, and 12.12 the
>> same day as 13.8.
>
>> In both cases queries against pg_stat_statements suddenly started taking
>> more memory leading to spillage to pg_temp and a step degradation in
>> overall performance. In at least one of those cases the
>> solution/workaround was to increase work_mem. In the other I think
>> pg_stat_statements was disabled.
>
>> Myself and at least one other hacker looked at the pg_stat_statements
>> specific changes in that time interval and saw no smoking gun.
>
>> But it is possible that something else backpatched to both branches
>> between Aug 09, 2021 and Aug 8, 2022 has caused a more general
>> performance regression which we have yet to track down.
>
> Hmm. My first instinct is to wonder about changes in plan selection.
> How complex were the troublesome queries?

I think both of these cases involved a number of common attributes:

* The queries against pg_stat_statements were
relatively complex
* The other queries on the system were relatively
long and complex (and thus the query string length
in pg_stat_statements)
* Prior to the upgrade the systems were overall
keeping up, but extremely busy

In one case it seems that the upgrade caused a significant increase of
temp file usage. This impacted the system enough that other active
queries took longer, and thus number of active connections increased.
Raising work_mem eliminated the temp file usage and cpu loads dropped
back to similar levels as they were prior to the minor upgrade.

The other case had different specifics, but generally involved increased
memory usage. In that one eliminating the use of pg_stat_statements
restored performance. They did not try raising work_mem (as I understand
it), and I did not get any info regarding temp file spillage there.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-10-01 19:45:55 Re: BUG #18141: sorry, too many clients error occurring very frequently
Previous Message Tom Lane 2023-10-01 18:09:48 Re: BUG #18141: sorry, too many clients error occurring very frequently