Message-ID: <F592F2DDBBFE4EBD82C9B785F14B4BE5@mia>
From: "Tom Fischer" <tom@timia.de>
To: <pgsql-admin@postgresql.org>
Subject: xlog-cleanup problem
Date: Wed, 5 Nov 2014 01:13:49 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_0C85_01CFF895.C162B1C0"
Importance: Normal
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Dies ist eine mehrteilige Nachricht im MIME-Format.

------=_NextPart_000_0C85_01CFF895.C162B1C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

we have some problems with the xlog-directory (size 5 GB). When we take =
a backup from one of our databases (about 80 GB data) and use an own =
script called by recovery.conf it begins to start the consumation of the =
wal-files fetched from our nas at a rate of about 2 per second.

Postgres just will not clean up the xlog-directory in time, so it runs =
full and next essential wal-file file could not be copied.
So my script stops for 5 minutes and sometimes the xlog is cleaned up a =
bit (from 100% to 84%) and the game starts again, there also has been =
some kind of lock and nothing happened until I restarted the cluster. On =
a restart the directory is cleaned up and about one half of the 5 GB =
will become available.

Checkpoint_segments are set to 64, wal-file-size is 16 MB, so at about =
300 wal-files the whole game is over even if there should never be more =
then 3 * 64 + xxx, what should be under 200.
Why do we get a lot more then 300 wal-files and what can we do against =
this, even 10 GB xlog-size is not enough to keep up some kind of =
balance.

With friendly regards=20
Tom Fischer
------=_NextPart_000_0C85_01CFF895.C162B1C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>Hello,</DIV>
<DIV>&nbsp;</DIV>
<DIV>we have some problems with the xlog-directory (size 5 GB). When we =
take a=20
backup from one of our databases (about 80 GB data) and use an own =
script called=20
by recovery.conf it begins to start the consumation of the wal-files =
fetched=20
from our nas at a rate of about 2 per second.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Postgres just will not clean up the xlog-directory in time, so it =
runs full=20
and next essential wal-file file could not be copied.</DIV>
<DIV>So my script stops for 5 minutes and sometimes the xlog is cleaned =
up a bit=20
(from 100% to 84%) and the game starts again, there also has been some =
kind of=20
lock and nothing happened until I restarted the cluster. On a restart =
the=20
directory is cleaned up and about one half of the 5 GB will become=20
available.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Checkpoint_segments are set to 64, wal-file-size is 16 MB, so at =
about 300=20
wal-files the whole game is over even if there should never be more then =
3 * 64=20
+ xxx, what should be under 200.</DIV>
<DIV>Why do we get a lot more then 300 wal-files and what can we do =
against=20
this, even 10 GB xlog-size is not enough to keep up some kind of =
balance.</DIV>
<DIV>&nbsp;</DIV>
<DIV>With friendly regards </DIV>
<DIV>Tom Fischer</DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0C85_01CFF895.C162B1C0--