Найти в Дзене
Postgres DBA

Комплексная методика статистического анализа производительности СУБД

Методика предназначена для выявления ключевых факторов, влияющих на рост ожиданий (событий ожидания) СУБД, и определения взаимосвязей между метриками производительности инфраструктуры (CPU, диск, память) и состоянием экземпляра базы данных. Анализ разделен на два взаимодополняющих блока: анализ ожиданий (3-этапный) и анализ метрик (2-этапный). Цель блока: Ранжирование типов событий ожидания по степени их влияния на общую нагрузку (суммарные ожидания) и отбор кандидатов для последующей оптимизации. На данном этапе производится первичный отсев случайных и статистически незначимых типов ожиданий. Для прошедших первый этап типов рассчитывается интегральная метрика, позволяющая отсеять типы с пренебрежимо малым вкладом, несмотря на статистическую значимость. Для каждого типа ожидания, прошедшего два предыдущих этапа, строится модель, количественно описывающая зависимость. Результат Блока А: Ранжированный список типов ожиданий, для которых построены статистически значимые регрессионные модел
Оглавление

1. Цель методики

Методика предназначена для выявления ключевых факторов, влияющих на рост ожиданий (событий ожидания) СУБД, и определения взаимосвязей между метриками производительности инфраструктуры (CPU, диск, память) и состоянием экземпляра базы данных.

Анализ разделен на два взаимодополняющих блока: анализ ожиданий (3-этапный) и анализ метрик (2-этапный).

БЛОК А. Трёхэтапный комплексный статистический анализ ожиданий СУБД (Waits Correlation Analysis)

Цель блока: Ранжирование типов событий ожидания по степени их влияния на общую нагрузку (суммарные ожидания) и отбор кандидатов для последующей оптимизации.

Этап 1: Оценка корреляции с суммарными ожиданиями (Фильтр значимости)

На данном этапе производится первичный отсев случайных и статистически незначимых типов ожиданий.

  • Действие: Для каждого типа события ожидания вычисляется коэффициент корреляции Пирсона между двумя временными рядами:
  • X – количество ожиданий конкретного типа за единицу времени.
  • Y – суммарное количество ожиданий всех типов (Total Waits) за ту же единицу времени.
  • Критерий отбора:
  • Если p-value ≥ 0.05 — корреляция статистически незначима (связь нестабильна или отсутствует). Тип ожидания исключается из дальнейшего анализа.
  • Если p-value < 0.05 — связь признается значимой. Тип ожидания переходит на Этап 2.

Этап 2: Расчёт взвешенной корреляции ожиданий (ВКО / WCC)

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

  • Действие: Рассчитывается показатель ВКО (Взвешенная корреляция ожиданий).
  • Формула (концепт): Метрика может учитывать как силу корреляции (коэффициент Пирсона), так и долю данного типа ожиданий в общей структуре (вес), чтобы исключить эффект «статистически значимых, но редких» событий.
  • Альтернативная трактовка: Может использоваться как квадрат коэффициента корреляции (r²), показывающий, какой процент вариативности суммарных ожиданий объясняется данным типом.
  • Критерий отбора:
  • Если ВКО < 0.01 — влияние типа ожидания на общую дисперсию признается пренебрежимо малым. Тип игнорируется.
  • Если ВКО ≥ 0.01 — тип ожидания признается значимым предиктором и передается на Этап 3.

Этап 3: Построение регрессионной модели и оценка прогностической силы

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

  • Действие: Строится простая линейная регрессия:Y=a+b⋅X где Y – суммарные ожидания, X – ожидания данного типа.
  • Оценка качества (по R2):
  • R2≥0.8 — Исключительно сильная модель. Тип ожидания является доминирующим драйвером общей нагрузки.
  • 0.6≤R2<0.8 — Качественная модель. Тип ожидания вносит основной вклад.
  • 0.4≤R2<0.6 — Приемлемая модель. Тип ожидания значим, но требуются дополнительные факторы для полной картины.
  • 0.2≤R2<0.4 — Слабая модель. Влияние присутствует, но не является определяющим.
  • R2<0.2 — Модель непригодна. Тип ожидания не подходит для прогнозирования поведения системы.

Результат Блока А: Ранжированный список типов ожиданий, для которых построены статистически значимые регрессионные модели. Тип с наибольшим R2 интерпретируется как основной фактор текущего роста ожиданий СУБД.

БЛОК Б. Двухэтапный комплексный статистический анализ метрик производительности (Performance Metrics Correlation Analysis)

Цель блока: Выявление взаимосвязей между состоянием СУБД (или подсистем) и метриками инфраструктуры для определения «узких мест» и подготовки данных для каузального (причинного) анализа.

Шаг 1: Оценка попарной корреляции метрик

Первичный анализ силы связи между рядами данных.

  • Действие: Вычисляется коэффициент корреляции Пирсона между двумя временными рядами:
  • Ряд №1: Метрика состояния (например, ожидания СУБД, количество процессов в очереди CPU (vmstat), количество операций ввода-вывода (iostat)).
  • Ряд №2: Метрика ресурса (например, утилизация CPU (vmstat), ожидание диска (iostat), свободная память).
  • Критерий отбора:
  • Если p-value ≥ 0.05 — корреляция статистически незначима. Связь между метриками признается нестабильной (ложная корреляция или её отсутствие). Пара исключается.
  • Если p-value < 0.05 — связь значима. Пара переходит на Шаг 2.

Шаг 2: Построение регрессионной модели и оценка влияния

Для значимых пар метрик строится модель, позволяющая понять, насколько изменение ресурса объясняет изменение состояния.

  • Действие: Строится линейная регрессия вида:Y=a+b⋅X где Y – значения Ряда №1 (состояние), X – значения Ряда №2 (ресурс).
  • Оценка качества (по R2):
  • Используется та же шкала оценки, что и в Блоке А (от 0 до 1, с градациями 0.2, 0.4, 0.6, 0.8).
  • Высокий R2R2 (например, > 0.6) говорит о том, что изменение метрики ресурса напрямую и линейно связано с изменением метрики состояния.

Результат Блока Б: Матрица взаимосвязей метрик. Пары с высоким R2 являются наиболее подходящими кандидатами для углубленного анализа.

Итоговый вывод и дальнейшие действия (Синергия методов)

  1. Блок А отвечает на вопрос «Чего именно ждет база данных?» (логические/физические чтения, блокировки, латентность ввода-вывода). Мы получаем конкретный тип события (например, db file sequential read).
  2. Блок Б отвечает на вопрос «Почему она это делает?» (какой ресурс перегружен). Мы получаем конкретную метрику инфраструктуры, наиболее сильно коррелирующую с состоянием СУБД (например, await из iostat).