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

Экспериментальный путь не быстрый, но по пути очень много интересного.

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

1. Продолжение тестирования PG_HAZEL на стандартных сценариях нагрузочного тестирования.

Сценарий 1 - "Select-only"

Сценарий 2 -"Select-Update"

Сценарий 3 - "Insert-Only"

Текущий эксперимент - Сценарий "Heawyweight"

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

**Установите значение max_worker_processes:**

- Обычно рекомендуется установить max_worker_processes равным количеству ядер процессора или немного меньше, чтобы избежать перегрузки системы. Например, если у вас 4 ядра, можно установить max_worker_processes в 3 или 4.

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

Версия СУБД

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

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

FOR counter IN 1..10000

LOOP

SELECT

gcd( ((random()*100.0) * (random()*100.0))::numeric , ((random()*100.0) * (random()*100.0))::numeric ) *

lcm( ((random()*100.0) * (random()*100.0))::numeric , ((random()*100.0) * (random()*100.0))::numeric )

* power(

gcd( ((random()*100.0) * (random()*100.0))::numeric , ((random()*100.0) * (random()*100.0))::numeric ) ,

lcm( ((random()*100.0) * (random()*100.0))::numeric , ((random()*100.0) * (random()*100.0))::numeric )

)

INTO current_result ;

END LOOP;

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

Эксперимент-1 : max_worker_processes = 8

Эксперимент-2 : max_worker_processes = 4

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

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

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

Ось X - нагрузка на СУБД . Ось Y - операционная скорость СУБД

Ось X - номер итерации. Ось Y - относительная разница операционной скорости в эксперименте-1 и эксперименте-2

Ось X - нагрузка на СУБД . Ось Y - медианное время выполнения тестового запроса

Ось X - номер итерации. Ось Y - относительная разница медианного времени тестового запроса в эксперименте-1 и эксперименте-2

Результат

Скорость выполнения тестового запроса в Эксперименте 2 увеличилась до ~3%

Время выполнения тестового запроса в Эксперименте 2 уменьшалась до 4% , затем относительная разница медианного начала снижаться.

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

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

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

Результаты

1. Количество инцидентов за время нагрузочного тестирования увеличилось с 2 до 4.

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

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

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

Результаты

1. Количество SQL запросов, имеющих ожидания увеличилось с 20 до 82.

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

Эксперимент-1( incident_id =11)

Эксперимент-2( incident_id =3)

Эксперимент-2( incident_id =4)

Эксперимент-2( incident_id =5)

Результаты

1. С ростом нагрузки в ходе Эксперимента-2 , отношение ожиданий к количеству вызовов увеличивается.

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

Эксперимент-1( incident_id =11)

Эксперимент-2( incident_id =3)

Эксперимент-2( incident_id =4)

Эксперимент-2( incident_id =5)

Результаты

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

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

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

1. Операционная скорость в ходе Эксперимента-2 увеличилась до 3%
2. Медианное время тестового запроса - практически не изменилось.
3. Уменьшение значения параметра max_worker_processes с 8 до 4 практически не оказало влияния на количество событий ожидания ProcArray.