|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Доброго времени суток! По мотивам Проблемы с логической репликацией, ошибок нет, но не работает. Собственно возник вопрос, а на сколько большим можно делать этот параметр? Поскольку для применения требуется рестарт постгрес-а, хочется выставить один раз с запасом. Провел эксперимент, на ВМ с 1цпу поднял до 30 и вроде все норм. Более того, не мог настроить модель лог. репликации 1 публикующий 4-е подписчика (все на одном сервере), пока не поднял параметр. Еще один вопрос, почему очень многие считают, что этот параметр отвечает за "распараллеливание" запросов? На сколько я понимаю, этот параметр отвечает за максимальное число процессов обслуживания запускаемых постгресом и НЕ обслуживающих запросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 11:37 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya На сколько я понимаю, этот параметр отвечает за максимальное число процессов обслуживания запускаемых постгресом и НЕ обслуживающих запросы. Неправильно понимаете... max_parallel_workers (integer) Sets the maximum number of workers that the system can support for parallel operations. The default value is 8. When increasing or decreasing this value, consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather. Also, note that a setting for this value which is higher than max_worker_processes will have no effect, since parallel workers are taken from the pool of worker processes established by that setting. Это общий лимит на любые процессы обслуживания кроме autovacuum (у них свой пул есть независимый). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 12:27 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya Доброго времени суток! По мотивам Проблемы с логической репликацией, ошибок нет, но не работает. Собственно возник вопрос, а на сколько большим можно делать этот параметр? Поскольку для применения требуется рестарт постгрес-а, хочется выставить один раз с запасом. Ну собственно как и max_connections (т.е. смотря по доступным ресурсам на сервере), background worker в совсем первом приближении обычный процесс базы просто не обслуживающий клиентские запросы. Можно и с запасом полсотни-сотню поставить если на сервере много памяти. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 12:29 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Вот опять не понятно. Т.е. пусть стоит значение по умолчанию 8, имеется одна потоковая реплика(walsender), это -1 из этого "пула", для меня это понятно Поднимаем одного подписчика, это -1(logical replication worker), когда устаканится, это то же понятно. Итого осталось 6 "слотов" в пуле. Но как это соотноситься с обслуживанием пользовательских запросов? Это просто число, ограничивающее количество процессов, которое может быть запущенно для обслуживания одного соединения? Т.е. 10 соединений запускают выборки, которые распараллеливаются, для КАЖДОГО доступно максимум max_worker_processes процессов (8 * 10) или это общее ограничение на все процессы и тогда для 10 соединений будет доступно 6 "слотов" (оставшихся), т.е. будет ожидание освобождения "слота"? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 12:43 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya Вот опять не понятно. Т.е. пусть стоит значение по умолчанию 8, имеется одна потоковая реплика(walsender), это -1 из этого "пула", для меня это понятно Поднимаем одного подписчика, это -1(logical replication worker), когда устаканится, это то же понятно. Итого осталось 6 "слотов" в пуле. Но как это соотноситься с обслуживанием пользовательских запросов? Это просто число, ограничивающее количество процессов, которое может быть запущенно для обслуживания одного соединения? Т.е. 10 соединений запускают выборки, которые распараллеливаются, для КАЖДОГО доступно максимум max_worker_processes процессов (8 * 10) или это общее ограничение на все процессы и тогда для 10 соединений будет доступно 6 "слотов" (оставшихся), т.е. будет ожидание освобождения "слота"? Могу только рекомендовать почитать внимательно доку...она не сложная... "это общее ограничение на все процессы и тогда для 10 соединений будет доступно 6 "слотов" (оставшихся)" - именно так. Ожидания никакого не будет, параллельное выполнение возьмёт столько workers сколько можно из свободных и будет с ними работать. Если свободных нет - значит без параллельного выполнения план пойдёт выполнятся в основном процессе. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 12:53 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Maxim Boguk "это общее ограничение на все процессы и тогда для 10 соединений будет доступно 6 "слотов" (оставшихся)" - именно так. Ожидания никакого не будет, параллельное выполнение возьмёт столько workers сколько можно из свободных и будет с ними работать. Если свободных нет - значит без параллельного выполнения план пойдёт выполнятся в основном процессе. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru Вот именно этот момент мне и не был понятен, спасибо! Доку читал, но дающееся там определение мне не понятно, если имеется пример, который описывает этот момент, подскажите почитаю\перечитаю. А теперь, собственно говоря про увеличение, не вижу "опасных" моментов. Например, max_worker_processes = 50 , из них свободно 30, а max_parallel_workers = 8, то все равно распараллеливание будет ограниченно 8 для всех процессов. Получается планку можно и слегка задрать, на будущее. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 13:10 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya А теперь, собственно говоря про увеличение, не вижу "опасных" моментов. Например, max_worker_processes = 50 , из них свободно 30, а max_parallel_workers = 8, то все равно распараллеливание будет ограниченно 8 для всех процессов. Получается планку можно и слегка задрать, на будущее. Собственно именно так я базы и настраиваю сейчас (max_worker_processes 32 или 64 а реальные лимиты через max_parallel_workers). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 13:24 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 13:26 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya Вот опять не понятно. Т.е. пусть стоит значение по умолчанию 8, имеется одна потоковая реплика(walsender), это -1 из этого "пула", для меня это понятно Хорошо когда понятно, плохо когда понятно неверно. max_wal_senders не входят в max_worker_processes. До pg12 max_wal_senders занимали коннекты из max_connections, начиная с 12 версии - добавляются дополнительно сверх Код: c 1. 2.
max_worker_processes - хард лимит сколько вообще может быть background workers в этом экземпляре postgresql, включая логическую репликацию, параллельные воркеры запросов, воркеры зарегистрированные расширениями и т.д.. Всё что использует инфраструктуру bgworkers max_parallel_workers - сколько слотов из max_worker_processes могут брать все параллельные запросы в пике на этом экземпляре postgresql. Именно потому что свободных слотов может не быть в explain analyze разные строки на сколько воркеров запустить хотели и сколько запустили max_parallel_workers_per_gather - сколько воркеров может запустить одна gather нода плана запроса max_parallel_maintenance_workers - сколько воркеров может взять parallel index create или параллельный vacuum (pg13) Итого соотношение max_worker_processes >= max_parallel_workers >= max_parallel_workers_per_gather (аналогично с max_parallel_maintenance_workers) Можно поставить большой max_parallel_workers_per_gather без проблем, но если не будет max_parallel_workers и max_worker_processes достаточно высокого - то столько воркеров мы не запустим. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 14:34 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Melkij Guzya Вот опять не понятно. Т.е. пусть стоит значение по умолчанию 8, имеется одна потоковая реплика(walsender), это -1 из этого "пула", для меня это понятно Хорошо когда понятно, плохо когда понятно неверно. max_wal_senders не входят в max_worker_processes. До pg12 max_wal_senders занимали коннекты из max_connections, начиная с 12 версии - добавляются дополнительно сверх Код: c 1. 2. 3. 4.
max_worker_processes - хард лимит сколько вообще может быть background workers в этом экземпляре postgresql, включая логическую репликацию, параллельные воркеры запросов, воркеры зарегистрированные расширениями и т.д.. Всё что использует инфраструктуру bgworkers max_parallel_workers - сколько слотов из max_worker_processes могут брать все параллельные запросы в пике на этом экземпляре postgresql. Именно потому что свободных слотов может не быть в explain analyze разные строки на сколько воркеров запустить хотели и сколько запустили max_parallel_workers_per_gather - сколько воркеров может запустить одна gather нода плана запроса max_parallel_maintenance_workers - сколько воркеров может взять parallel index create или параллельный vacuum (pg13) Итого соотношение max_worker_processes >= max_parallel_workers >= max_parallel_workers_per_gather (аналогично с max_parallel_maintenance_workers) Можно поставить большой max_parallel_workers_per_gather без проблем, но если не будет max_parallel_workers и max_worker_processes достаточно высокого - то столько воркеров мы не запустим. У меня вот есть слабая надежда что со временем wal_senders и autovacuum_workers начнут браться из общего пула max_worker_processes и не требовать рестарта для увеличения. Версии эдак к 16... Выделенные независимые от max_worker_processes и отдельно управляемые отдельным кодом пулы max_wal_senders и autovacuum_max_workers - это печально (т.е. понятно почему: "исторический артефакт" и даже "почему не сделали нормально сейчас" -тоже понятно). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 14:40 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Melkij Итого соотношение max_worker_processes >= max_parallel_workers >= max_parallel_workers_per_gather (аналогично с max_parallel_maintenance_workers) Больше интересует max_worker_processes >= logical replication worker + max_parallel_workers + воркеры из расширений(timescaledb, и т.д.) + еще что + запас? Т.е. хочется понять, кто входит (может упираться) в этот параметр. И кого надо посчитать, чтоб затыков не устраивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 15:22 |
|
max_worker_processes на сколько большим можно делать?
|
|||
---|---|---|---|
#18+
Guzya, а кто попросит - те и входят, это довольно generic механизм max_parallel_workers и max_logical_replication_workers штатные (вроде всё) + что угодно в расширениях Maxim Boguk У меня вот есть слабая надежда что со временем wal_senders и autovacuum_workers начнут браться из общего пула max_worker_processes и не требовать рестарта для увеличения. Версии эдак к 16... А потом на выбор между: - у нас реплика отстала, т.к. walreceiver не смог пробиться, все слоты были заняты - чехарда взаимосвязанных настроек. Я уже как-то раз даже Тому писал, когда он спутал max_worker_processes с max_parallel_workers и удивлялся эффекту... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2021, 15:42 |
|
|
start [/forum/topic.php?fid=53&msg=40122425&tid=1993740]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 124ms |
0 / 0 |