PG_HAZEL : cводная отчетность по производительности СУБД PostgreSQL.

Для решения проблемы нужен взгляд с разных точек зрения.

Архивный материал. Методика устарела или не используется.

Начало

Постановка задачи

Анализ результатов отчета "Отчет по инцидентам за период времени (incidents_to_timepoint)".

Разделы отчета

1.Общая информация по инцидентам снижения скорости СУБД

2.Количество SQL запросов по инцидентам

3.Количество инцидентов для SQL запросов

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

5.Итог

1.Общая информация по инцидентам снижения скорости СУБД

Отчет по инцидентам снижения скорости СУБД с 00:00 - 08:00

Приоритеты инцидентов

По оси X - id инцидента. По оси Y - приоритет ( 4 или 3 ) .

По оси X - id инцидента. По оси Y - приоритет ( 4 или 3 ) .

Результат

80% инцидентов составляют инциденты приоритета 4.

Длительности инцидентов

По оси X - id инцидента. По оси Y -длительность инцидента в минутах.

По оси X - id инцидента. По оси Y -длительность инцидента в минутах.

Результат

Длительность 80% инцидентов составляют 20 и более минут.

Снижение операционной скорости

По оси X - id инцидента. По оси Y - относительное снижение операционной скорости (%) на начало инцидента.

Результат

Инциденты с приоритетом 4 могут иметь высокое значение относительного снижения скорости.

Ожидания СУБД

По оси X - id инцидента. По оси Y -коэффициент корреляции между ожиданиями СУБД и ожиданиями конкретного типа.

По оси X - id инцидента. По оси Y -коэффициент корреляции между ожиданиями СУБД и ожиданиями конкретного типа.

Ожидания типа IPC встречается во всех инцидентах.

Результат

Наибольшая корреляция между ожиданиями СУБД и ожиданиями типа IPC.

2.Количество SQL запросов по инцидентам

Таблица отсортирована по количеству SQL запросов.

По оси X - id инцидента. По оси Y - Количество SQL запросов .

Результат

Наибольшее количество запросов имеет инцидент 142.

3.Количество инцидентов для SQL запросов

Фрагмент таблицы . Значения отсортированы по количеству инцидентов для данного SQL запроса.

Результат

SQL запросы с queryid = -4040189995000405452 и -2983227928459178773 выполняются во всех инцидентах.

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

Сводная таблица по количеству SQL запросов по событиям ожиданий wait_event

Гистограмма количества SQL запросов по событиям ожиданий

По Оси X - событие ожидания (wait_event). По оси Y - количество SQL запросов при выполнении которых возникает данное событие ожидания.

Диаграмма Парето по количеству SQL запросов по событиям ожиданий

Количество SQL запросов по событиям ожиданий по типа IPC(наибольшая корреляция с событиями ожиданий СУБД ).

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

Гистограмма количества SQL запросов по событиям ожиданий по типа IPC(наибольшая корреляция с событиями ожиданий СУБД ).

По Оси X - событие ожидания (wait_event). По оси Y - количество SQL запросов при выполнении которых возникает данное событие ожидания типа IPC.

Диаграмма Парето по количеству SQL запросов по событиям ожиданий по типа IPC(наибольшая корреляция с событиями ожиданий СУБД ).

По Оси X - событие ожидания (wait_event). По оси Y - количество SQL запросов при выполнении которых возникает данное событие ожидания типа IPC.

Результат

Наибольшее количество запросов по типу ожидания IPC возникает по событиям ожидания BgWorkerShutdown и ParallelFinish.

• BgWorkerShutdown : Ожидание завершения фонового рабочего процесса.
• ParallelFinish : Ожидание завершения вычислений параллельными рабочими процессами.

Мероприятия для снижения количества ожиданий BgWorkerShutdown:

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

Мероприятия для снижения количества ожиданий ParallelFinish:

1. Оптимизация запросов.

2. Настройка параметров параллелизма:

• Параметр max_parallel_workers_per_gather определяет максимальное количество параллельных рабочих процессов, которые могут быть использованы для одного оператора Gather. Уменьшение этого параметра может снизить количество параллельных операций и, следовательно, количество ожиданий ParallelFinish.
• Параметр parallel_setup_cost определяет стоимость настройки параллельного плана. Увеличение этого параметра может сделать параллельные планы менее привлекательными для оптимизатора, что может привести к использованию менее параллельных планов.

3. Использование правильных настроек для агрегации:

• Если запросы включают агрегацию, убедитесь, что агрегатные функции поддерживают параллелизм. Если они не поддерживают, это может привести к увеличению ожиданий ParallelFinish.

4. Оптимизация ресурсов:

• Убедитесь, что у вас достаточно ресурсов (CPU, память) для эффективного выполнения параллельных операций. Недостаток ресурсов может привести к увеличению времени ожидания.

5.Итог

Сводные отчеты по производительности СУБД позволяют установить:

1. Относительное количество инцидентов по приоритетам и длительности за период анализа.
2. Установить значения деградации скорости СУБД при возникновении инцидентов.
3. Определить тип ожидания имеющий наибольшую корреляцию со снижением скорости СУБД в ходе инцидентов - цель глубинного анализа со стороны СУБД , приложения и инфраструктуры.
4. Определить количество SQL запросов по инцидентам.
5. Определить SQL запросы имеющиеся в наибольшем количестве инцидентов для начала работ по оптимизации на уровне SQL.