☑️ Материал подготовлен с помощью нейросети DeepSeek. Не для публикации на Хабре.
От интегральной корреляции к событийно-ориентированному пространству состояний: методология сбора и кластеризации raw-событий ожидания PostgreSQL, построение марковской модели переходов между агрегированными wait-состояниями, адаптивное забывание и комбинированный прогноз риска деградации производительности на основе цепочек блокировок
Начало
1. Анализ существующей реализации и выявление ограничений
Текущее состояние модели :
- Пространство состояний: 189 дискретных состояний, определяемых комбинацией:
- correlation (скоррелированность операционной скорости и времени ожидания, шаг 0.1 от –1.0 до +1.0)
- os_trend (тренд операционной скорости: –1, 0, +1)
- wait_trend (тренд времени ожидания: –1, 0, +1)
- Источник данных: таблица cluster_stat_median (агрегированные метрики производительности кластера)
- Обучение: однозначный переход каждую минуту, логирование в transition_log, обновление частот
- Прогноз риска: поглощающая матрица для аварийных состояний (отрицательная корреляция + снижение os_trend + рост wait_trend)
Ограничения текущей модели для анализа цепочек ожиданий:
- Не использует напрямую события ожидания PostgreSQL (wait_event_type / wait_event из pg_stat_activity)
- Работает с обобщённой корреляцией, что даёт интегральный риск, но не позволяет диагностировать конкретные цепочки блокировок (например, LWLock:BufferContent → IO:DataFileRead)
- Частота дискретизации (1 минута) может быть недостаточной для захвата быстрых переходов между событиями ожидания (субминутные паттерны)
2. Расширение источников данных: сбор цепочек ожиданий
2.1. Внедрение сбора raw-событий ожидания
Использовать расширение pg_wait_sampling (доступно с PostgreSQL 9.6+) для периодического снимка событий ожидания всех процессов
Создать таблицу wait_event_snapshots со следующими колонками:
ts (TIMESTAMPTZ NOT NULL) – время снимка
pid (INT NOT NULL) – идентификатор процесса
wait_event_type (TEXT) – тип события ожидания
wait_event (TEXT) – конкретное событие
state (TEXT) – состояние процесса
query_id (BIGINT) – идентификатор запроса
Настроить фоновый сбор (например, каждые 5–10 секунд) через background worker
2.2. Формирование цепочек ожиданий по процессам
Для каждого процесса (pid) за период активной сессии построить временную последовательность событий ожидания:
- Сгладить шум: убрать быстрое переключение между несущественными состояниями (фильтр скользящего большинства или минимальная длительность)
Сохранять цепочки в таблицу wait_event_chains:
chain_id (BIGSERIAL) – первичный ключ
pid (INT) – идентификатор процесса
start_ts (TIMESTAMPTZ) – время начала цепочки
end_ts (TIMESTAMPTZ) – время окончания цепочки
events (TEXT[]) – массив wait_event в порядке следования
3. Определение пространства состояний на основе событий ожидания
3.1. Агрегация событий в значимые состояния
- Слишком много raw-событий (более 200). Необходимо кластеризовать их в разумное число состояний (10–30) на основе:
- Группировки по wait_event_type (Lock, LWLock, IO, Client, Activity, Extension…)
- Дополнительной детализации для самых частых типов (например, отдельные состояния для LWLock:BufferContent, LWLock:WALWrite)
- Экспертных правил из документации PostgreSQL
Создать справочник wait_state_descriptions с колонками:
state_id (SMALLINT PRIMARY KEY) – идентификатор состояния
state_name (TEXT NOT NULL) – например, 'LWLock_BufferContent', 'IO_DataFileRead'
wait_event_type (TEXT) – тип события
wait_event (TEXT) – событие
is_absorbing (BOOLEAN DEFAULT FALSE) – флаг аварийного/поглощающего состояния
3.2. Функция приведения snapshot’а к состоянию
Реализовать get_wait_state_for_process(pid, ts) RETURNS SMALLINT, которая для данного процесса в момент времени возвращает идентификатор состояния на основе текущего wait_event (или NULL, если процесс активен)
Для агрегации по кластеру: основное состояние системы в момент времени – это наиболее часто встречающееся wait_event_type среди всех активных процессов (или состояние с максимальным временем ожидания)
4. Модификация модели цепи Маркова для анализа цепочек ожиданий
4.1. Новая таблица переходов для wait-событий
Аналог transition_log, но с более высокой частотой (каждые 5–10 секунд):
id (BIGSERIAL PRIMARY KEY)
ts (TIMESTAMPTZ NOT NULL)
from_state (SMALLINT NOT NULL)
to_state (SMALLINT NOT NULL)
process_pid (INT NULL) – опционально для индивидуальных цепочек
Индексы по (ts, from_state) и (from_state, to_state)
4.2. Обучение цепи (адаптация mchain_train_step)
Создать отдельную функцию wchain_train_step(), вызываемую с частотой сбора (например, каждые 10 секунд)
Логика:
- Получить текущее состояние системы на основе агрегированных wait events
- Если предыдущее состояние существует – записать переход в wait_transition_log
- Обновить wait_frequencies (аналог markov_frequencies для wait-состояний)
- Периодически (например, раз в 10 шагов) пересчитывать вероятности и применять забывание
4.3. Оценка марковского свойства для wait-цепочек
Добавить диагностическую функцию check_markov_property_wait(), которая для реальных цепочек вычисляет:
- Среднюю длину корреляции (на основе partial autocorrelation)
- Сравнение вероятностей переходов первого и второго порядка (тест отношения правдоподобия)
- Результат сохранять в markov_config как wait_markov_verified
5. Прогнозирование риска на основе цепочек ожиданий
5.1. Определение аварийных состояний в wait-пространстве
Аварийными считать состояния, соответствующие:
- Длительным блокировкам (Lock:transactionid, Lock:tuple)
- Деградации ввода-вывода (IO:DataFileRead с высоким временем)
- Сочетаниям, предшествующим deadlock’ам (по историческим данным)
- В таблице wait_state_descriptions установить флаг is_absorbing = TRUE
5.2. Функции прогноза риска (адаптация mchain_predict_risk_k)
Создать wchain_predict_risk_k(k INT) с использованием поглощающей матрицы wait_absorbing
Шаг прогноза – интервал дискретизации (например, 10 секунд). Для удобства добавить обёртки:
- wchain_predict_risk_1min
- wchain_predict_risk_5min
- (вычисляют количество шагов)
Учитывать возможность неизвестного состояния (например, если текущее состояние не встречалось в обучении) – возвращать априорный риск
5.3. Комбинированный риск
Итоговый риск инцидента производительности можно рассчитывать как взвешенную сумму:
- Риск на основе корреляции (старая модель) – для общих трендов
- Риск на основе wait-цепочек – для специфических блокировок
- Веса настраиваются через markov_config (например, wait_model_weight = 0.7)
6. Расширение таблиц конфигурации и метаданных
6.1. Новая конфигурация для wait-модели
Добавить в markov_config (или создать wait_markov_config) следующие поля:
- wait_sampling_interval_sec (INT DEFAULT 10) – интервал сбора wait-событий
- wait_min_transitions_for_forgetting (INT DEFAULT 5000) – порог числа переходов для включения забывания
- wait_absorbing_states (TEXT[]) – список названий аварийных состояний
6.2. Таблицы для wait-частот и вероятностей
- wait_frequencies (from_state, to_state, frequency)
- wait_probabilities
- wait_absorbing
- Все строятся по аналогии с существующими, но с ключом по wait_state_id
6.3. Журнал забывания для wait-модели
- Можно использовать единую таблицу apply_forgetting_log с дополнительной колонкой model_type ('correlation' / 'wait_chain')
7. Адаптация механизма забывания и достаточности данных
7.1. Раздельная проверка достаточности
Реализовать wchain_check_sufficiency(), проверяющую:
- Общее число переходов в wait_transition_log ≥ порога
- Стабильность вероятностей для wait-состояний (аналог mchain_forecast_reliability)
- Автоматическое включение забывания для wait-модели через wchain_enable_forgetting_when_sufficient()
7.2. Адаптивный alpha для wait-модели
Использовать те же принципы:
- alpha = base_alpha * exp(-days_since_incident / half_life)
- Базовый alpha может быть другим (например, 0.05 для более быстрой адаптации к изменяющимся паттернам блокировок)
- Параметры: wait_base_alpha, wait_min_alpha, wait_incident_half_life_days
8. Интеграция с существующими функциями очистки и логирования
Расширить mchain_clean_transition_log (или создать wchain_clean_transition_log) для удаления старых записей из wait_transition_log
Адаптировать mchain_clean_apply_forgetting_log для фильтрации по модели
Использовать общую таблицу mchain_error_log для ошибок в wait-функциях
9. Мониторинг и отладка для wait-цепочек
9.1. Функции текущего состояния
- wchain_get_current_state() – возвращает wait_state_id текущего агрегированного состояния системы
- wchain_get_process_chain(pid, interval) – показывает цепочку ожиданий для конкретного процесса за заданный интервал
9.2. Отчёт достоверности
Дополнить mchain_reliability_report() секцией по wait-модели:
- Рейтинг достоверности для wait-цепочек (0–5)
- Рекомендации по настройке частоты сбора
10. Поэтапный план внедрения
Подготовка (1 неделя)
- Создание таблиц для сбора snapshot’ов
- Написание скрипта сбора
Разработка состояний (1 неделя)
- Анализ wait-событий на реальной нагрузке
- Кластеризация событий
- Создание справочника wait_state_descriptions и функции get_wait_state_id()
Реализация базовой цепи (2 недели)
- Создание таблиц wait_frequencies, wait_transition_log
- Функция wchain_train_step (без забывания)
- Тестовое обучение
Прогнозирование (1 неделя)
- Реализация wchain_predict_risk_k и поглощающей матрицы
- Проверка на исторических данных о инцидентах
Забывание и достаточность (1 неделя)
- Адаптация wchain_apply_forgetting
- wchain_check_sufficiency
- Интеграция с markov_config
Интеграция с существующей моделью (1 неделя)
- Функция комбинированного риска
- Настройка весов
- Автоматический выбор модели
Тестирование и документирование (2 недели)
- Нагрузочное тестирование
- Сравнение точности прогнозов старой и новой модели
- Написание документации
11. Ожидаемые результаты
- ➡️Возможность предсказывать инциденты производительности, связанные с конкретными цепочками блокировок (например, «через 10 минут высокая вероятность deadlock из-за накопления LWLock:BufferContent»)
- ➡️Повышение точности прогноза за счёт использования более детерминированных сигналов (wait events) вместо косвенной корреляции
- ➡️Диагностические отчёты: «ваша система 80% времени проводит в состоянии IO:DataFileRead, переход в LWLock:WALWrite с вероятностью 0.3 ведёт к деградации за 15 минут»
- ➡️Единая архитектура, позволяющая в будущем добавлять другие источники состояний (например, статистику индексов, размер очереди блокировок)
12. Рекомендации по дальнейшему развитию
- Использовать скрытые марковские модели (HMM) для учёта ненаблюдаемых факторов (например, внутренних очередей ОС)
- Внедрить неоднородные цепи Маркова с учётом времени суток и дня недели (циклическая нагрузка)
- Автоматическое определение аварийных состояний на основе исторических инцидентов (обучение с учителем)
Данный план полностью опирается на существующую реализацию pg_expecto и расширяет её в направлении анализа цепочек ожиданий, сохраняя обратную совместимость и модульность.