Re: Excessive PostmasterIsAlive calls slow down WAL redo
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-24T07:37:40Z
Lists: pgsql-hackers
On Sat, Apr 21, 2018 at 12:25:27PM +1200, Thomas Munro wrote:
> Here's a new version, because FreeBSD's new interface changed slightly.
I have been looking at the proposed set for Linux, and the numbers are
here. By replaying 1GB worth of WAL after a pgbench run with the data
folder on a tmpfs the recovery time goes from 33s to 28s, so that's a
nice gain.
Do you have numbers with FreeBSD? I get that this would be more
difficult to set up without a GA release perhaps...
I can also see the difference in profiles by looking for
HandleStartupProcInterrupts which gets close 10% of the attention when
unpatched, and down to 0.1% when patched.
@@ -2484,6 +2484,8 @@ ClosePostmasterPorts(bool am_syslogger)
if (bonjour_sdref)
close(DNSServiceRefSockFD(bonjour_sdref));
#endif
+
+ PostmasterDeathInit();
Thomas, trying to understand here... Why this place for the signal
initialization? Wouldn't InitPostmasterChild() be a more logical place
as we'd want to have this logic caught by all other processes?
--
Michael
Commits
-
Poll postmaster less frequently in recovery.
- 57dcc2ef3320 14.0 landed
-
Use signals for postmaster death on FreeBSD.
- f98b8476cd4a 12.0 landed
-
Use signals for postmaster death on Linux.
- 9f09529952ac 12.0 landed
-
Introduce a pipe between postmaster and each backend, which can be used to
- 89fd72cbf26f 9.2.0 cited