Re: explosive WAL growth

From: vignesh kumar <vigneshkumar(dot)venugopal(at)outlook(dot)com>
To: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: explosive WAL growth
Date: 2024-02-27 19:50:41
Message-ID: MN0PR20MB4912F0A887A1FC6A07754F5087592@MN0PR20MB4912.namprd20.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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.

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
Sent: Tuesday, February 27, 2024 11:39:58 PM
To: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
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(at)elevated-dev(dot)com
https://www.linkedin.com/in/scottribe/

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message venkatesh R 2024-02-28 03:30:07 PG Role : With Crud Operations without Drop DB user
Previous Message Scott Ribe 2024-02-27 19:19:25 Re: explosive WAL growth