pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedDelay in converting logs from ready state to done state
3+ messages / 2 participants
[nested] [flat]
* Delay in converting logs from ready state to done state
@ 2016-10-12 05:26 Samir Magar <samirmagar8@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Samir Magar @ 2016-10-12 05:26 UTC (permalink / raw)
To: pgsql-performance
Team,
we are seeing delay in converting logs from ready state to done state in
pg_xlog archive status.
we have seen pg_xlog generated 2000 per hour and it is getting archived
1894. So the speed at which the archiving is done is too slow as compare to
the pg_xlog generation
So our pg_xlog directory keeps filling regularly. What should be the real
cause here?
We cannot see any specific error on pg_log except no space left on device.
current setting:
wal_level = archive
archive_mode = on
max_wal_senders = 3
archive_command = 'gzip < %p > /pgarchive/%f'
checkpoint_segments = 3
checkpoint_timeout = 5min
log_checkpoints = on
archive_timeout = 60
Thanks,
Samir Magar
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Delay in converting logs from ready state to done state
@ 2016-10-12 06:03 Julien Rouhaud <julien.rouhaud@dalibo.com>
parent: Samir Magar <samirmagar8@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Julien Rouhaud @ 2016-10-12 06:03 UTC (permalink / raw)
To: Samir Magar <samirmagar8@gmail.com>; pgsql-performance
On 12/10/2016 07:26, Samir Magar wrote:
> Team,
>
> we are seeing delay in converting logs from ready state to done state in
> pg_xlog archive status.
>
> we have seen pg_xlog generated 2000 per hour and it is getting archived
> 1894. So the speed at which the archiving is done is too slow as compare
> to the pg_xlog generation
>
> So our pg_xlog directory keeps filling regularly. What should be the
> real cause here?
>
> We cannot see any specific error on pg_log except no space left on device.
>
>
>
> current setting:
>
> wal_level = archive
>
> archive_mode = on
>
> max_wal_senders = 3
>
> archive_command = 'gzip < %p > /pgarchive/%f'
>
You could use pigz which is parallel, that could speed up compression.
> checkpoint_segments = 3
>
this is way to low. If you generate 2000 WAL per hour, you should
configure it to something like 170 (or 5 min average if 2000 is a
spike). It'll perform less checkpoint and also generate less WALs.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
^ permalink raw reply [nested|flat] 3+ messages in thread
* Fwd: Delay in converting logs from ready state to done state
@ 2016-10-12 07:04 Samir Magar <samirmagar8@gmail.com>
parent: Julien Rouhaud <julien.rouhaud@dalibo.com>
0 siblings, 0 replies; 3+ messages in thread
From: Samir Magar @ 2016-10-12 07:04 UTC (permalink / raw)
To: pgsql-performance@postgresql.org, Julien Rouhaud <julien.rouhaud@dalibo.com>
*Hello Julien,*
*Thank you for your prompt response!*
*we have changed the checkpoint_segment to 170 and use pigz for the pg_xlog
compress.*
*It is working very well now.*
*Thanks again!!*
*Regards,*
*Samir Magar*
On Wed, Oct 12, 2016 at 11:33 AM, Julien Rouhaud <julien.rouhaud@dalibo.com>
wrote:
> On 12/10/2016 07:26, Samir Magar wrote:
> > Team,
> >
> > we are seeing delay in converting logs from ready state to done state in
> > pg_xlog archive status.
> >
> > we have seen pg_xlog generated 2000 per hour and it is getting archived
> > 1894. So the speed at which the archiving is done is too slow as compare
> > to the pg_xlog generation
> >
> > So our pg_xlog directory keeps filling regularly. What should be the
> > real cause here?
> >
> > We cannot see any specific error on pg_log except no space left on
> device.
> >
> >
> >
> > current setting:
> >
> > wal_level = archive
> >
> > archive_mode = on
> >
> > max_wal_senders = 3
> >
> > archive_command = 'gzip < %p > /pgarchive/%f'
> >
>
> You could use pigz which is parallel, that could speed up compression.
>
> > checkpoint_segments = 3
> >
>
> this is way to low. If you generate 2000 WAL per hour, you should
> configure it to something like 170 (or 5 min average if 2000 is a
> spike). It'll perform less checkpoint and also generate less WALs.
>
>
> --
> Julien Rouhaud
> http://dalibo.com - http://dalibo.org
>
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2016-10-12 07:04 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-10-12 05:26 Delay in converting logs from ready state to done state Samir Magar <samirmagar8@gmail.com>
2016-10-12 06:03 ` Julien Rouhaud <julien.rouhaud@dalibo.com>
2016-10-12 07:04 ` Samir Magar <samirmagar8@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox