Re: [GENERAL] Too long startup time after each crash.

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: [GENERAL] Too long startup time after each crash.
Дата
Msg-id eed17976-b6d2-3d8c-a4ca-ebc208139e7b@aklaver.com
обсуждение исходный текст
Ответ на Re: [GENERAL] Too long startup time after each crash.  (neos@olansoft.com)
Список pgsql-general
On 12/21/2016 06:53 PM, neos@olansoft.com wrote:
> 22.12.2016, 06:31, "Adrian Klaver" <adrian.klaver@aklaver.com>:
>>
>> Alright looks like it doing the correct thing.
>>
>> Now if I am following you say you see the issue starting with 9.5+. As
>> it so happens that is when checkpoint_segments was replaced with
>> max_wal_size:
>


>> If you had not changed the checkpoint_settings in your 9.4- servers it
>> would have been set at 3 or roughly 48 MB of WALs. In 9.5 max_wal_size
>> is set at 1GB. In either case the default checkpoint_timeout would be 5
>> minutes.
>>
>> Did you change the checkpoint_timeout setting or is you machine
>> generating something close to 1GB of WAL files before the 5 minutes?
>
> Hm... No, i have never changed checkpoint_timeout setting (and wal_size in 9.5\9.6 too).
>
> In 9.4 config i have had checkpoint_segments = 32 and checkpoint_completion_target = 0.9
> In 9.3 checkpoint_segments = 8 and checkpoint_completion_target = 0.7
>
> Generally i have about 3 to 5 WAL files per 24h (copied to destination by archive_command)

So a max of 80MB over 24hrs, to me that is not enough to make a
difference in recovery time.

>
>>
>> Either case could lead to longer start up times as Postgres would have
>> to process more WAL files.
>>
>> There is also your checkpoint_completion_target = 0.85. The default is
>> 0.5. Per the docs below:
>> "The disadvantage of this is that prolonging checkpoints affects
>> recovery time, because more WAL segments will need to be kept around for
>> possible use in recovery."
>
> Hmm, i don't think about that. I set it to "0.5". Now i'm waiting for the next failure, or do it manually nearest
nightlol. 

Given your slow rate of WAL production I would not expect that to make a
difference.

Next time Postgres is in recovery and assuming you can catch it you
might want to:

ps ax to see what is running.

Run iostat

Check the OS system logs for any clues.

>
>>
>> For more information see 9.4-:
>>
>> https://www.postgresql.org/docs/9.4/static/wal-configuration.html
>>
>> 9.5+:
>>
>> https://www.postgresql.org/docs/9.5/static/wal-configuration.html
>>
>>
>> --
>> Adrian Klaver
>> adrian.klaver@aklaver.com
>


--
Adrian Klaver
adrian.klaver@aklaver.com


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [GENERAL] UTF-8 on Postgres wire protocol
Следующее
От: Dylan Luong
Дата:
Сообщение: [GENERAL] pgaudit_analyze process filling up audit log file