Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table - Mailing list pgsql-performance

From Joshua Banton
Subject Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table
Date
Msg-id CAHkYM9YXAXGbmWTNhPGMHjS2zgcuOYsXjQr2B1h2CS3KO5E=NQ@mail.gmail.com
Whole thread Raw
In response to Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-performance
There are not that many tables, 175. 

There are a decent number of transactions on the database, 35k a second during the day. I ran a vacuum verbose on table1 today and got this output on the pages frozen.

frozen: 2813436 pages from table (0.70% of total) had 7028123 tuples frozen



On Fri, Jan 31, 2025 at 5:46 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Fri, Jan 31, 2025 at 5:28 PM Joshua Banton <bantonj@gmail.com> wrote:
> The issue mostly manifests near the end of the "scanning heap" phase of vacuuming of one of our largest tables, we'll call table1. RDS Performance Insights reports that selects on table1 start to wait on cpu, where previously it didn't even show up in the top 25 queries by wait. It doesn't always happen, but if there is a larger than usual number of selects on table1 it is more likely to happen.

Does this database also have many tables? As in thousands of tables?

I am reminded of this issue:

https://www.postgresql.org/message-id/flat/da3205c4-5b07-a65c-6c26-a293c6464fdb%40postgrespro.ru

I've heard of this happening when an aggressive VACUUM updates
relfrozenxid on a larger table.

--
Peter Geoghegan

pgsql-performance by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table
Next
From: Jon Emord
Date:
Subject: Poor performance with row wise comparisons