Re: Excessive PostmasterIsAlive calls slow down WAL redo
От | Michael Paquier |
---|---|
Тема | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Дата | |
Msg-id | 20180424073740.GB15322@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Excessive PostmasterIsAlive calls slow down WAL redo (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Excessive PostmasterIsAlive calls slow down WAL redo
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: