From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Date: | 2018-04-25 06:23:26 |
Message-ID: | CAEepm=0w9AAHAH73-tkZ8VS2Lg6JzY4ii3TG7t-R+_MWyUAk9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 24, 2018 at 7:37 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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.
Thanks for testing.
> Do you have numbers with FreeBSD? I get that this would be more
> difficult to set up without a GA release perhaps...
I don't have production build numbers, but a similar test to yours
went from 91s to 61s on a debug kernel in a virtual machine.
> 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?
Yeah, you're right. Here's one like that.
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
0001-Use-signals-for-postmaster-death-on-Linux-v4.patch | application/octet-stream | 8.7 KB |
0002-Use-signals-for-postmaster-death-on-FreeBSD-v4.patch | application/octet-stream | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2018-04-25 06:31:12 | Re: [HACKERS] Clock with Adaptive Replacement |
Previous Message | Nick Dro | 2018-04-25 06:21:25 | Racing DEADLOCK on PostgreSQL 9.3 |