ReSQL.ru
     
powered by simpleCommunicator - 2.0.19     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / checkpointer и большой shared_buffers
25 сообщений из 25, страница 1 из 1
checkpointer и большой shared_buffers
    #40134998
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
После интенсивного ввода-вывода, сочетающегося с большими значениям shared_buffers, получаем затяжной шатдаун базы с длительной работой checkponter. Что не так? Как можно это побороть?
...
Рейтинг: 0 / 0
18.02.2022, 01:08
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135000
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
После интенсивного ввода-вывода, сочетающегося с большими значениям shared_buffers, получаем затяжной шатдаун базы с длительной работой checkponter. Что не так? Как можно это побороть?


Никак надо же дать базе время чтобы гигабайты грязных данных на диск сбросить...

Что именно побороть требуется?
Длительный shutdown - попробуйте сделать checkpoint руками ДО остановки базы - это неблокирующая операция (а лучше несколько раз его сделать), после чего уже сразу стопать/рестартовать базу не давая ей накопить опять много грязных страниц.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 01:39
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135002
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,
С таким поведением ни разу не сталкивался в контексте Oracle, поэтому выглядит крайне необычно
На самом деле, даже не связано с большим размером shared_buаfers
Но происходит примерно так:
а)интенсивный ввод-вывод
б)останов последнего (из пункта а)
в)попытка остановить базу блокируетя архидлительной работой checkpointer. Гораздо дольше, чем длился сам ввод-вывод. При том, что устройство хранения отнюдь не из медленных
...
Рейтинг: 0 / 0
18.02.2022, 01:46
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135003
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,
С таким поведением ни разу не сталкивался в контексте Oracle, поэтому выглядит крайне необычно
На самом деле, даже не связано с большим размером shared_buаfers
Но происходит примерно так:
а)интенсивный ввод-вывод
б)останов последнего (из пункта а)
в)попытка остановить базу блокируетя архидлительной работой checkpointer. Гораздо дольше, чем длился сам ввод-вывод. При том, что устройство хранения отнюдь не из медленных


в)потому что пока вы делаете а) особо активной записи в файлы данных не происходит - данные пишутся ЛИНЕЙНО в WAL большими блоками (и там важна производительность на линейную запись а на latency более менее пофигу)

а когда в делаете остановку или checkpoint - эти изменённые данные начинают писаться уже не в wal (они там есть) а в файлы данных где начинается вопрос random IO и соответственно IOPS и главное latency на эти IOPS (особенно учитывая что checkpoint он однопоточный и в 10-100 потоков dirty buffers на диск скидывать не умеет и из за этого крайне сильно зависим даже не от предельных IOPS дисковой системы а именно от задержек, так как если дисковая система может 1М IOPS выдывать а latency 1ms - checkpoint не сможет больше 1000IOPS использовать).

Особенно это конечно видно на hdd storage где latency на последовательный и случайный доступ отличается на 3 порядка.

В общем а) - линейная запись не подверженная задержкам а в)случайная запись лимитированная latency (и даже не IOPS)

PS: попробуйте максимально агрессивно bgwriter настроить (немного остроту проблемы снизит).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 02:05
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135004
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,
То, что вы говорите, боле-менее понятно и довольно традиционно
Но не хотелось бы считать это фичей postgres, т.к. очевидно, что здесь возникает проблема с RTO
Надеюсь, частоту сбросов и синхронность сбросов можно отрегулировать с помощью параметров checkpoint, хотя для меня это не до конца ясно пока что
...
Рейтинг: 0 / 0
18.02.2022, 02:26
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135006
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,
То, что вы говорите, боле-менее понятно и довольно традиционно
Но не хотелось бы считать это фичей postgres, т.к. очевидно, что здесь возникает проблема с RTO
Надеюсь, частоту сбросов и синхронность сбросов можно отрегулировать с помощью параметров checkpoint, хотя для меня это не до конца ясно пока что


Непонятен use case вообще, частые checkpoints крайне дорогие по IO и вредны для производительности базы.
Обычно стараются их максимально редко делать (в идеале совсем редко но тут уже SLA на recovery после сбоя базы страдать начинает).
Т.е. зачем вам быстрая остановка базы в любое время вообще (этого в теории можно добиться но ценой очень резкого роста IO на сервере)? Тем более внеплановая быстрая остановка... а плановую я описал как сделать быстро.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 02:38
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135007
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Так я уже говорю даже не про остановку, а про RTO (т.е. время восстановления), что с точки зрения промышленной базы важно таки.
checkpoint-ы вредны для производтительности, но полезны для сохранности данных (снижение нагрузки на файлы журналов при восстановлении)
...
Рейтинг: 0 / 0
18.02.2022, 02:41
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135008
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Так я уже говорю даже не про остановку, а про RTO (т.е. время восстановления), что с точки зрения промышленной базы важно таки.
checkpoint-ы вредны для производтительности, но полезны для сохранности данных (снижение нагрузки на файлы журналов при восстановлении)


Ну про это я как раз и написал в части "(в идеале совсем редко но тут уже SLA на recovery после сбоя базы страдать начинает)."
Тут уже надо max_wal_size тюнить исходя из требуемого SLA на recovery после сбоя (RTO).
Причём именно max_wal_size а не checkpoint_timeout.
Разумный баланс тут уже каждый для себя выбирает, моя best practice ориентироваться на RTO между 5 и 30 минутами (но встречался с ситуациями когда RTO меньше часа оказывается запретительным с т.з. роста обьёма WAL и нагрузки на диски).

Частые checkpoints ещё сильно объём файлов журналов увеличивают (бывает и на порядок) из-за механизма full page writes
см https://www.postgresql.org/docs/14/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
в части full_page_writes

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 02:59
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135010
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Т.е., на самом деле, частота сбросов определяется max_wal_size? Если нет, то здесь, по идее, возникнет противоречие. Если так долго идет сброс блоков из оперативной памяти, то recovery из журналов будет соответствовать по объему и длиться еще дольше?
...
Рейтинг: 0 / 0
18.02.2022, 03:17
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135011
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Собственно, документация намекает именно на это. Все ясно
...
Рейтинг: 0 / 0
18.02.2022, 03:30
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135012
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Хотя и не до конца. Во врем указанной и кратковременной высокой нагрузки также наблюдается активная работа checkpointer при относительно большом размере max_wal_size(10G). Сходится, но не во всем :(
...
Рейтинг: 0 / 0
18.02.2022, 03:34
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135094
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Покажите

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
select name,setting,unit,context 
from pg_settings 
where name in ('checkpoint_timeout'
            ,'checkpoint_completion_target'
            ,'max_wal_size'
            ,'bgwriter_delay'
            ,'bgwriter_flush_after'
            ,'bgwriter_lru_maxpages'
            ,'bgwriter_lru_multiplier'
            ,'full_page_writes') 
order by name;


select * from pg_stat_bgwriter \gx
...
Рейтинг: 0 / 0
18.02.2022, 11:46
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135098
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Т.е., на самом деле, частота сбросов определяется max_wal_size? Если нет, то здесь, по идее, возникнет противоречие. Если так долго идет сброс блоков из оперативной памяти, то recovery из журналов будет соответствовать по объему и длиться еще дольше?


max_wal_size определяет максимальный размер журнала... после достижения которого начинается автоматический checkpoint,
соответственно именно этот размер определяет то сколько журнала надо будет проиграть заново в самом плохом случае после сбоя (т.е. время требуемое на RTO) связь конечно не совсем линейная но близкая к таковой.
checkpoint_timeout просто задаёт периодичность выполнения принудительных checkpoint вне зависимости от того сколько данных записали (хоть вообще записи не было).

Т.е. checkpoint может триггерится по 2м событиям - 1)достижение max_wal_size или 2)прошло checkpoint_timeout с момента предыдущего checkpoint.

Регулировать RTO через checkpoint_timeout не очень удачная идея так как когда записи мало/нет - они будут слишком часто происходить, а когда очень много записи - недостаточно часто (если max_wal_size большой).

PS: да recovery из журнала будет дольше чем просто сброс блоков прежде всего потому что она начинается на холодных кешах и на диск надо будет не только писать но ещё и читать активно.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 11:58
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135102
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Хотя и не до конца. Во врем указанной и кратковременной высокой нагрузки также наблюдается активная работа checkpointer при относительно большом размере max_wal_size(10G). Сходится, но не во всем :(


Мог сработать checkpoint_timeout или база достигла max_wal_size
Для более подробного анализа ситуации/или любопытства можно включить log_checkpoints в конфиге базы
и посматривать за select * from pg_stat_bgwriter ; в процессе работы

PS: checkpoint это не мгновенное действие а некий длительный процесс сброса грязных страниц на диск.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 12:05
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135113
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk
Maxim Boguk,

Регулировать RTO через checkpoint_timeout не очень удачная идея так как когда записи мало/нет - они будут слишком часто происходить, а когда очень много записи - недостаточно часто (если max_wal_size большой).


чуваки из EDB с вами не согласны

max_wal_size
Checkpoints should always be triggered by a timeout for better performance and predictability. The max_wal_size parameter should be used to protect against running out of disk space by ensuring a checkpoint occurs when we reach this value to enable WAL to be recycled. The recommended value is half to two-thirds of the available disk space where the WAL is located.
...
Рейтинг: 0 / 0
18.02.2022, 12:32
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135125
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk
Maxim Boguk,

Регулировать RTO через checkpoint_timeout не очень удачная идея так как когда записи мало/нет - они будут слишком часто происходить, а когда очень много записи - недостаточно часто (если max_wal_size большой).


чуваки из EDB с вами не согласны

max_wal_size
Checkpoints should always be triggered by a timeout for better performance and predictability. The max_wal_size parameter should be used to protect against running out of disk space by ensuring a checkpoint occurs when we reach this value to enable WAL to be recycled. The recommended value is half to two-thirds of the available disk space where the WAL is located.


Для задачи " for better performance and predictability" - лучше checkpoint по timeout (там вполне предсказуемо RTO может быть очень большим).
Для задаче "заданный RTO" checkpoint по timeout - очевидно что нет, потому что после сбоя сервера в момент пиковой записи проиграть 300GB max_wal_size после сбоя сервера занимает часы даже на ОЧЕНЬ быстрых дисках (там оно тупо в CPU 1ядро упрётся).

минимизация RTO (или достижение заданного RTO) при условии неровной нагрузки на записи - оно противоположно настройкам к требованиям максимума производительности.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 13:06
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135132
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Хорошо, на аналогии с Oracle. Можно обрушить базу с очень толстым redo, который полностью записан. При этом время восстановления может быть минимальным, т.к. все даные уже в файлах бд
Думаю, логика с большим max_wal_size может быть схожей, но пока не понимаю
...
Рейтинг: 0 / 0
18.02.2022, 13:25
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135139
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Хорошо, на аналогии с Oracle. Можно обрушить базу с очень толстым redo, который полностью записан. При этом время восстановления может быть минимальным, т.к. все даные уже в файлах бд
Думаю, логика с большим max_wal_size может быть схожей, но пока не понимаю


С большим max_wal_size ситуация будет аналогичной... если он уже полностью записан - то и восстановление будет тоже минимальным по времени.
А вот если обрушить базу с толстым max_wal_size когда он в основном не записан (т.е. большая его часть была записана после последнего завершённого checkpoint) - он будет весь проигрываться.

Т.е. если был сбой базы - то redo (wal) начинает проигрываться с отметки последнего успешного checkpoint, который мог быть как и 1kb wal назад так и многие десятки гигабайт назад если max_wal_size позволяет.
Т.е. max_wal_size ограничивает максимальное количество проигрываемого после сбоя redo в самом плохом случае, в реальности оно будет от 0 и до worst case (смотря когда именно сбой произошёл).

Наверное вам интересно будет почитать https://www.postgresql.org/docs/14/wal-configuration.html

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 13:49
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135140
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Имеется в виду, что редо заполнен, но чекпойнты были раньше и все данные уже в файлах бд, а проблема в том случае, если он (redo-файл) был записан очень быстро, и грязные блоки не успели сбросить. В этом случае восстановление может быть более долгим
...
Рейтинг: 0 / 0
18.02.2022, 13:52
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135142
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Имеется в виду, что редо заполнен, но чекпойнты были раньше и все данные уже в файлах бд, а проблема в том случае, если он (redo-файл) был записан очень быстро, и грязные блоки не успели сбросить. В этом случае восстановление может быть более долгим


Ровно таже ситуация в postgresql. Осложнённая тем что redo в postgresql он однопоточный и легко упирается или в IO latency или в single core cpu performance.

PS: я не знаю как в oracle в деталях но в postgresql redo после сбоя проигрывается от момента последнего успешного checkpoint даже если какие то из этих данных механизм bgwriter или незавершённый checkpoint уже внёс в файлы базы.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 13:56
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135145
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk,

Да, так и есть. Учет счетчика scn

Но в этом случае не вижу проблемы в гипотезе EDB. Единственно, в противоречии с возможным архивированием, но с этим еще не успел разобраться
...
Рейтинг: 0 / 0
18.02.2022, 14:06
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135150
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Allbest
Maxim Boguk,

Да, так и есть. Учет счетчика scn

Но в этом случае не вижу проблемы в гипотезе EDB. Единственно, в противоречии с возможным архивированием, но с этим еще не успел разобраться


В гипотезе EDB проблема что она предполагает равномерную запись... а у вас по постановке "После интенсивного ввода-вывода", т.е. нагрузка не ровная а пиковая.
Далее, предположим что вы поставили checkpoint timeout в 10 минут (и max_wal_size с запасом на любой случай - т.е. много).
Но за эти 10 минут база может как 100kb wal написать так и 100GB если оборудование позволяет и было столько записи от приложения (тот самый пик записи).
В этих 2х случаях recovery time будет совсем разный и вполне возможно что 100GB redo проиграть в требуемый RTO не будет влезать.

Если же ставить очень маленький checkpoint_timeout так чтобы база физически не могла записать много данных между 2мя checkpoint по времени - они при средней-низкой нагрузке будут наоборот идти слишком часто и негативно влиять на дисковую нагрузку.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 14:22
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135177
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Maxim Boguk

...
Ровно таже ситуация в postgresql. Осложнённая тем что redo в postgresql он однопоточный и легко упирается или в IO latency или в single core cpu performance.

PS: я не знаю как в oracle в деталях но в postgresql redo после сбоя проигрывается от момента последнего успешного checkpoint даже если какие то из этих данных механизм bgwriter или незавершённый checkpoint уже внёс в файлы базы.

AFAIK в Oracle кроме "классического", есть еще и Incremental checkpoint
...
Рейтинг: 0 / 0
18.02.2022, 16:18
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135188
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Leonid Kudryavtsev
Maxim Boguk

...
Ровно таже ситуация в postgresql. Осложнённая тем что redo в postgresql он однопоточный и легко упирается или в IO latency или в single core cpu performance.

PS: я не знаю как в oracle в деталях но в postgresql redo после сбоя проигрывается от момента последнего успешного checkpoint даже если какие то из этих данных механизм bgwriter или незавершённый checkpoint уже внёс в файлы базы.

AFAIK в Oracle кроме "классического", есть еще и Incremental checkpoint


Я думаю что он как раз сделан для решения обсуждаемой проблемы (RTO vs checkpoint performance/overhead).
В PostgreSQL этого к сожалению нет на данном этапе.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
18.02.2022, 16:56
| Ответить | Цитировать | Написать  
checkpointer и большой shared_buffers
    #40135196
Allbest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Allbest
Гость
Maxim Boguk


Если же ставить очень маленький checkpoint_timeout так чтобы база физически не могла записать много данных между 2мя checkpoint по времени - они при средней-низкой нагрузке будут наоборот идти слишком часто и негативно влиять на дисковую нагрузку.


Думаю, они намекают, что рулить таки через checkpoint_timeout в соответствии с профилем нагрузки системы. Нахожу это разумным.
...
Рейтинг: 0 / 0
18.02.2022, 17:14
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / checkpointer и большой shared_buffers
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
Start [/forum/topic.php?fid=53&tid=1993652]:
 0ms
get settings:
 2ms
get forum list:
 10ms
check forum access:
 0ms
check topic access:
 0ms
track hit:
 9ms
get topic data:
 2ms
get forum data:
 1ms
get page messages:
 24ms
get tp. blocked users:
 0ms
others: 84ms
total:  132ms
созд. / загр.: 132ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]