Re: explosive WAL growth

Поиск
Список
Период
Сортировка
От vignesh kumar
Тема Re: explosive WAL growth
Дата
Msg-id MN0PR20MB4912F0A887A1FC6A07754F5087592@MN0PR20MB4912.namprd20.prod.outlook.com
обсуждение исходный текст
Ответ на explosive WAL growth  (Scott Ribe <scott_ribe@elevated-dev.com>)
Список 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.


From: Scott Ribe <scott_ribe@elevated-dev.com>
Sent: Tuesday, February 27, 2024 11:39:58 PM
To: Pgsql-admin <pgsql-admin@lists.postgresql.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@elevated-dev.com
https://www.linkedin.com/in/scottribe/





В списке pgsql-admin по дате отправления:

Предыдущее
От: Scott Ribe
Дата:
Сообщение: Re: explosive WAL growth
Следующее
От: venkatesh R
Дата:
Сообщение: PG Role : With Crud Operations without Drop DB user