| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Joshua Banton <bantonj(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table |
| Date: | 2025-01-31 22:45:48 |
| Message-ID: | CAH2-WzmZEQn7jH3iYZvsgMJ93Z=POaGcgu4BSF73_vSgoZUKcg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Jan 31, 2025 at 5:28 PM Joshua Banton <bantonj(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Banton | 2025-01-31 22:59:42 | Re: High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table |
| Previous Message | Joshua Banton | 2025-01-31 22:28:16 | High System CPU Usage on Selects Seemingly Caused By Vacuum of Same Table |