Re: Excessive PostmasterIsAlive calls slow down WAL redo

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Excessive PostmasterIsAlive calls slow down WAL redo
Дата
Msg-id CAEepm=0w9AAHAH73-tkZ8VS2Lg6JzY4ii3TG7t-R+_MWyUAk9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On Tue, Apr 24, 2018 at 7:37 PM, Michael Paquier <michael@paquier.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Fsync request queue
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: [HACKERS] Clock with Adaptive Replacement