PG_HAZEL : Влияние изменения параметра max_parallel_workers_per_gather на скорость и ожидания СУБД.

Результаты экспериментов иногда могут быть очень интересными

Задача эксперимента

1.Проверка рекомендаций ChatPPG

Задержки, связанные с блокировкой ProcArrayLock, могут возникать из-за интенсивной активности рабочих процессов, которые создают конкуренцию за доступ к ProcArray.

Настройка параметров конфигурации:

- Настройте параметры, связанные с параллелизмом, такие как max_parallel_workers_per_gather и max_worker_processes, чтобы управлять количеством рабочих процессов.

Для снижения количества ожиданий ProcArray, вам, скорее всего, нужно уменьшить значение параметра max_parallel_workers_per_gather.

Этот параметр определяет максимальное количество рабочих процессов,

которые могут быть запущены для одного оператора Gather.

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

Цитаты из ответов ChatPPG.

2. Продолжение исследований о связи утилизации CPU и ожиданий СУБД

Версия СУБД

Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu

Виртуальная машина

cat /proc/cpuinfo

processor       : 0

model name      : Intel Xeon Processor (Skylake, IBRS, no TSX)

cpu MHz         : 2693.670

processor       : 1

model name      : Intel Xeon Processor (Skylake, IBRS, no TSX)

cpu MHz         : 2693.670

Тестовый запрос

SELECT MAX(aid) INTO max_i FROM pgbench_accounts ;

current_aid = max_i / 2;

select br.bbalance

into test_rec

from pgbench_branches br

join pgbench_accounts acc on (br.bid = acc.bid )

where acc.aid =  current_aid ;

Сравнительные эксперименты

Эксперимент 1 : max_parallel_workers_per_gather = 4

Эксперимент 2 : max_parallel_workers_per_gather = 2

Операционная скорость и медианное время тестового SQL запроса

Ось X - номер итерации. Ось Y - значение операционной скорости.

Ось X - номер итерации. Ось Y - значение медианного времени выполнения тестового SQL запроса.

Результат

Скорость тестового запроса в Эксперименте 2 - несколько уменьшилась.

Время выполнения тестового запроса в Эксперименте 2 - практически не изменилось.

Инциденты производительности в ходе нагрузочного тестирования

Эксперимент 1

Эксперимент 2

Результаты

1. Количество инцидентов снижения производительности СУБД - снизилось: 6/2.
2. Снижение скорости - существенно снизилось: 86% / 8% .

Количество SQL запросов по событиям ожидания (wait_event)

Эксперимент 1

Эксперимент 2

Результаты

1. Количество SQL запросов, имеющих ожидания - существенно снизилось: 124 / 42.
2. Количество SQL запросов, имеющих ожидания ProcArray - существенно снизилось: 14 / 6 .

Статистические показатели по SQL запросам по событию ожидания LWLock

Эксперимент 1

Эксперимент 2

• Эксперимент 1 - Отношение ожидания / количество запросов : 0,009005812943685
• Эксперимент 2 - Отношение ожидания / количество запросов : 3,915017128199936e-4

Результаты

1. Отношение ожидания к количеству запросов уменьшилось на порядки.

Ожидания по тестовому SQL запросу

Эксперимент 1

Эксперимент 2

Результаты

1. Количество ожидания ProcArray - уменьшилось на порядки.
2. Ожидания LockManager в эксперименте 2 - отсутствуют.

Выводы по результатам сравнительных экспериментов

В данной конфигурации , при заданном характере нагрузки :

1. Снижение значения параметра max_parallel_workers_per_gather кардинально снижает ожидания ProcArray.
2. Снижение количества ожиданий ProcArray не дает прироста скорости СУБД .
3. Рекомендации ChatPPG - работают и могут быть использованы при оптимизации производительности СУБД.
4. Снижение значения параметра max_parallel_workers_per_gather в 2 раза, привело к уменьшению отношения ожиданий ProcArray к запросам на 2 порядка.