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  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: "could not reattach to shared memory" on buildfarm member dory
Следующее
От: Pierre Ducroquet
Дата:
Сообщение: [RFC] Add an until-0 loop in psql