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, так что в конце концов есть один процесс, который имеет дело с I-O. Это зависит от системы, но все же, один процесс.

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