Postgresql 10 - параллельная настройка

Question

Существует 4 конфигурации для включения параллели и оптимизации, но в документации PostgreSQL ничего не говорится о значениях или вычислениях. Мои вопросы:

1- Как рассчитать значения max_parallel_workers, max_parallel_workers_per_gather а также max_worker_processes?

2- work_mem можно рассчитать на основе соединений и памяти (RAM), но work_mem нужно что-то изменить, если я включу параллель?

Мое предположение: если машина имеет 8 ядер the max_parallel_workers равно 8, а значения рабочего процесса и за сборку составляют 32(8*4), число 4, которое я взял из исходной конфигурации, равно 4 сборкам за 1 параллельную работу.

Answer 1

После некоторых поисков я нашел несколько ответов, это может помочь тем, кто хочет включить и иметь базовую конфигурацию, если у вас 4 ядра (ЦП):

ваши максимальные рабочие процессы будут равны количеству ядер, а максимальная параллель должна иметь одинаковое количество:

max_worker_processes = 4
max_parallel_workers = 4

сбор более сложный, потому что этим значением можно манипулировать в зависимости от ваших потребностей и ресурсов, которые необходимо протестировать, чтобы получить наилучшее значение, но для запуска значений вы можете использовать core /2.

max_parallel_workers_per_gather = 2

Это не окончательный ответ, есть некоторые пропущенные моменты... Я все еще ищу и обновляю этот ответ или жду лучшего.

Answer 2

Есть небольшая симпатичная онлайн-утилита конфигурации, которая помогает установить основные значения postgresql.conf.

Это не идеально, но дает отправную точку, которая может быть полезной.

https://pgtune.leopard.in.ua/

Answer 3

Вопрос вполне очевиден, но ответа нет.

Я постараюсь описать это немного шире, так что если что-то кажется вам очевидным - просто пропустите это.

Первое - как это работает, описано здесь. Для чего эти параметры описаны здесь. Другими словами - PG имеет пул процессов, которые могут что-то делать в фоновом режиме. Максимальное количество из них ограничено max_worker_processes, Когда сканирование таблицы выполняется, это может занять много-много времени, поэтому было бы разумно иметь больше процессов, которые принимают данные. Это может быть сделано в фоновом режиме,... фоновыми работниками. Узел плана запроса, который может быть выполнен ими: gather, gather-merge,

Каждый фоновый работник имеет свою память - для сортировки и других вещей, связанных с выполнением. Они там всегда, поэтому лучше иметь это в виду, просто чтобы система не использовала своп...

Кроме того. Постарайтесь определить наилучшее количество работников на запрос - по умолчанию это равно 2. Так что, если все работает нормально, для сбора данных используются два фоновых работника. Следующий вопрос - сколько запросов выполняется параллельно. Я имею в виду - это тяжелые запросы, требующие параллельной обработки. Имея эти два числа, скажем, 4 рабочих на запрос и 10 запросов, нужно 40 рабочих, только для этого. Вы можете рассчитать, если это нормально, или поэкспериментировать с этим. Так или иначе - есть еще один параметр - max_worker_processes, Имея эти 40 рабочих для параллельной обработки - вам нужно больше рабочих для других задач, таких как репликация.

Это 40 звучит разумно? Здесь есть два контрапункта - по умолчанию PG - это база данных OLTP. Таким образом, система подготовлена ​​для чего-то другого, и такого рода изменения могут принести хорошие результаты. С другой стороны - есть один bgwriterтак что в конце концов есть один процесс, который имеет дело с IO. Это зависит от системы, но все же, один процесс.

Так что ответ далек от совершенства - вам нужно постараться собрать собственную статистику и принять решение.