From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | valgog(at)gmail(dot)com |
Subject: | Re: BUG #7494: WAL replay speed depends heavily on the shared_buffers size |
Date: | 2012-08-15 14:09:54 |
Message-ID: | 201208151609.54315.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On Wednesday, August 15, 2012 12:10:42 PM valgog(at)gmail(dot)com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7494
> Logged by: Valentine Gogichashvili
> Email address: valgog(at)gmail(dot)com
> PostgreSQL version: 9.0.7
> Operating system: Linux version 2.6.32-5-amd64 (Debian 2.6.32-41)
> Description:
>
> We are experiencing strange(?) behavior on the replication slave machines.
> The master machine has a very heavy update load, where many processes are
> updating lots of data. It generates up to 30GB of WAL files per hour.
> Normally it is not a problem for the slave machines to replay this amount
> of WAL files on time and keep on with the master. But at some moments, the
> slaves are “hanging” with 100% CPU usage on the WAL replay process and 3%
> IOWait, needing up to 30 seconds to process one WAL file. If this tipping
> point is reached, then a huge WAL replication lag is building up quite
> fast, that also leads to overfill of the XLOG directory on the slave
> machines, as the WAL receiver is putting the WAL files it gets via
> streaming replication the XLOG directory (that, in many cases are quite a
> limited size separate disk partition).
Could you try to get a profile of that 100% cpu time?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-08-15 15:08:21 | Re: BUG #7495: chosen wrong index |
Previous Message | psql | 2012-08-15 13:52:29 | BUG #7495: chosen wrong index |