Check the Wal_keep_size or wal_keep_segments if they are too huge occupying the wal space.
Take a waldump and see what's really going on. Usually the blob will have wals split into multiple chunks to accomodate the filemaps.
Also use slot based replication so that primary need not maintain all the wals .. instead it maintains only wals required for the slot to have it replicated.
Check the min wal size and max wal size..
If none of them helps.. your application is shooting up load.
From: Scott Ribe <scott_ribe@xxxxxxxxxxxxxxxx>
Sent: Tuesday, February 27, 2024 11:39:58 PM
To: Pgsql-admin <pgsql-admin@xxxxxxxxxxxxxxxxxxxx>
Subject: explosive WAL growth
Sent: Tuesday, February 27, 2024 11:39:58 PM
To: Pgsql-admin <pgsql-admin@xxxxxxxxxxxxxxxxxxxx>
Subject: explosive WAL growth
Something is causing our WAL to grow 160GB/hour *faster* than archiving. (Archiving appears to be working normally.) This started in the past couple of days.
I am having some trouble finding the cause of this. I am looking at pg_stat_statements, # calls, time, shared blocks written. I am also looking at recent client app deployments.
My next step might be to use something like pg_waldump to see what's in this WAL.
Any suggestions?
--
Scott Ribe
scott_ribe@xxxxxxxxxxxxxxxx
https://www.linkedin.com/in/scottribe/
I am having some trouble finding the cause of this. I am looking at pg_stat_statements, # calls, time, shared blocks written. I am also looking at recent client app deployments.
My next step might be to use something like pg_waldump to see what's in this WAL.
Any suggestions?
--
Scott Ribe
scott_ribe@xxxxxxxxxxxxxxxx
https://www.linkedin.com/in/scottribe/
