From: | Jamie Koceniak <jkoceniak(at)mediamath(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #9635: Wal sender process is using 100% CPU |
Date: | 2014-05-07 03:02:22 |
Message-ID: | 84CE67AB46ACDA41B18094177DD0853D212F58@ORD2MBX04C.mex05.mlsrvr.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Andres,
The ssl option is on in postgres.conf but we don't have any hostssl lines or cert configured as an authentication method in our pg_hba.conf file.
In our pg_hba.conf we have configured each replication host as trust:
host replication all xx.xxx.xxx.xx/32 trust
I replied in a previous email that we have a job that inserts 30+ million records into a table.
During the loading of this table, the wal_sender cpu spikes to 100% and appears to stay at 100% until the replication is completed on the slave.
I have been able to reproduce this. Other than offloading this job, is there anything we can do to improve the replication lag?
Thanks!
-----Original Message-----
From: Andres Freund [mailto:andres(at)2ndquadrant(dot)com]
Sent: Tuesday, May 06, 2014 3:42 PM
To: Jamie Koceniak
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #9635: Wal sender process is using 100% CPU
Hi,
On 2014-03-19 17:13:56 +0000, jkoceniak(at)mediamath(dot)com wrote:
> Periodically throughout the day, we keep seeing the wal sender process
> utilize 100% of the CPU. We began noticing this after we added 2 new
> slave servers, going from 2 to 4 slaves. See top results and I also
> included our wal settings. Thanks!
A typical reason for this is that the standbys are connecting over ssl. Is that the case? If so, intentionally?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | dlo | 2014-05-07 04:32:48 | BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password |
Previous Message | Cécile Tonglet | 2014-05-07 01:46:20 | pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path |