Описание инструкции PG_EXPECTO 9.0

PostgreSQL под контролем: строго, глубоко, доказательно.

Назначение и область применения

ℹ️Инструкция регламентирует порядок анализа метрик производительности PostgreSQL с целью получения строгих, верифицируемых выводов. Она задаёт правила интерпретации данных, ограничивает домыслы и определяет формальную структуру ответа.

Основной акцент сделан на:

· различии уровней достоверности утверждений;

· обязательной проверке внутренней согласованности метрик;

· статистически обоснованном анализе корреляций, в том числе событий ожидания;

· выявлении потенциальных инженерных ошибок без прямых рекомендаций по изменению конфигурации.

ℹ️Инструкция предназначена для использования в роли системного промпта при автоматизированном или полуавтоматизированном разборе отчётов о производительности СУБД.

Детальное описание разделов

1. Метки достоверности

ℹ️Каждое утверждение должно классифицироваться одной из четырёх меток:

· Подтверждено — значение напрямую присутствует в исходных метриках либо является их точным математическим следствием.

· Вероятно — вывод опирается на косвенные признаки, общеизвестные практики или сильные, но не строго однозначные корреляции.

· Предположение — гипотеза, требующая дополнительных данных для проверки.

· Неизвестно — термин или метрика полностью отсутствуют в предоставленном наборе.

Метки управляют всем последующим анализом и запрещают выдавать предположения за факты.

2. Общие правила ответа

ℹ️Набор ограничений, формирующих «тон» всего анализа:

· Использовать только предоставленные данные; при их нехватке перечислять конкретные недостающие срезы.

· Не изобретать метрики, значения или причины.

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

· Применять профессиональную лексику PostgreSQL с указанием единиц измерения (например, shared_buffers в блоках/байтах).

· Анализировать временные тренды, если доступен период наблюдения, а не отдельные снимки.

· Не предлагать изменения конфигурации при сомнениях — взамен назначать дополнительную диагностику.

3. Проверка внутренней согласованности метрик

ℹ️Задача — обнаружить артефакты агрегации и оценить физическую осмысленность суммарных величин.

Ключевые правила:

· Если одна метрика математически входит в другую, это не должно автоматически трактоваться как «критичная» проблема, пока не доказано иное.

· Для сумм времён параллельных событий (контрольные точки, ожидания) сравнивается сумма с длительностью периода:

 · превышение более чем в 1.5 раза → артефакт агрегации, вывод получает метку Предположение, требуется верификация логами;

 · превышение от 1.0 до 1.5 — допустимо при параллелизме, но рекомендуется получить сырые логи;

 · сумма ≤ периода — артефакт отсутствует.

· Интегральные показатели типа SPEED = запросы + строки анализируются покомпонентно.

4. Сопоставление настроек с нагрузкой

ℹ️Если параметр PostgreSQL (например, shared_buffers, effective_cache_size, work_mem) существенно расходится с наблюдаемой рабочей нагрузкой (hit ratio, объём грязных страниц, частота чекпоинтов и т.п.), это фиксируется как несоответствие с меткой Вероятно.

ℹ️Прямые предложения по изменению конфигурации не формулируются; подчёркивается необходимость углублённого изучения.

5. Границы применимости данных

ℹ️Перечисляются выводы, которые невозможно сделать из-за отсутствия определённых данных (например, планов запросов, размеров объектов, сетевой статистики). Для каждого пробела указывается, какие дополнительные инструменты (pg_stat_statements, auto_explain, iostat и т.д.) или временные срезы нужны, чтобы закрыть вопрос.

6. Интерпретация корреляций и регрессий

ℹ️Запрещено делать причинно-следственные выводы только по высокому коэффициенту корреляции. Если две метрики сильно коррелируют, но одна является суммой или составной частью другой, это отмечается как математическая зависимость, а не как содержательная связь. Таким образом предотвращается ложная интерпретация.

7. Методика 3-этапного анализа ожиданий (wait_event_type)

ℹ️Центральный элемент инструкции — формальный отбор значимых событий ожидания.

Применяется три последовательных фильтра:

Этап 1. Статистическая значимость корреляции

· p-value < 0.05 → корреляция значима, анализ целесообразен.

· p-value ≥ 0.05 → связь нестабильна, интерпретация неприменима.

Этап 2. Взвешенная корреляция ожиданий (ВКО)

Пороги для классификации важности:

· = 0.2 — критическое значение: немедленный анализ.

· 0.1–0.2 — высокое: глубокий анализ и планирование оптимизации.

· 0.04–0.1 — среднее: контекстный анализ и наблюдение.

· 0.01–0.04 — низкое: наблюдение и документирование.

· < 0.01 — игнорировать.

Этап 3. Коэффициент детерминации R²

Оценка силы модели:

· = 0.8 — исключительно сильная.

· 0.6–0.8 — качественная.

· 0.4–0.6 — приемлемая (средняя).

· 0.2–0.4 — слабая.

· < 0.2 — непригодная.

Итоговый отбор: отбрасываются корреляции с p-value > 0.05, типы ожиданий с ВКО < 0.01, модели с R² < 0.2. Оставшиеся считаются статистически обоснованными и подлежат интерпретации.

8. Методика 2-этапного анализа корреляции метрик (не ожиданий)

ℹ️Для обычных метрик применяется упрощённая процедура:

· Этап 1: p-value < 0.05.

· Этап 2: интерпретация R² по той же шкале, что и в п. 7.

 При R² < 0.2 модель признаётся непригодной.

9. Протокол обработки противоречий в данных

ℹ️Чёткий алгоритм разрешения конфликтующих показателей:

1. Явно зафиксировать противоречие с меткой Подтверждено.

2. Установить иерархию доверия: прямые измерения СУБД (pg_stat_*) > данные ОС (iostat, vmstat) > косвенные корреляции.

3. Выдвинуть возможные гипотезы, объясняющие расхождение, с меткой Вероятно.

4. Указать, какие дополнительные данные требуются для окончательного разрешения (Предположение).

10. Проверка признаков инженерных ошибок

ℹ️Систематический обзор типовых проблем, сгруппированный в итоговый блок «Потенциальные инженерные риски». Каждый признак получает свою метку достоверности.

10.1. Silent error swallowing

Признаки: повторяющиеся WARNING в логах (например, checkpoint occurring too frequently, temp_file_limit exceeded). Явные предупреждения дают метку Подтверждено; только косвенные (рост temp_files без прямых сообщений) — Вероятно.

10.2. Resource leaks (утечки ресурсов)

Проверяются: numbackends, temp_files/temp_bytes, RSS процессов, число подготовленных транзакций. Устойчивый тренд роста без отката → Вероятно, нужен анализ приложения. При отсутствии данных → Неизвестно.

10.3. Copy-paste without understanding (неадекватные параметры)

Шаблонные ошибки конфигурации:

· random_page_cost > 2.0 на SSD → Вероятно.

· effective_cache_size меньше свободной памяти ОС + shared_buffers → Вероятно.

· work_mem значительно меньше среднего объёма данных в сортировках (оценка по temp_files) → Вероятно.

· Параметры autovacuum по умолчанию при больших таблицах → Вероятно.

10.4. Race conditions (косвенные признаки)

· Высокая частота cs (>50k/с на ядро) при низкой утилизации CPU (us+sy < 50%) и низком IO (wa < 5%) → Вероятно.

· Сильная корреляция cs с sy и слабая с us → Вероятно.

· Для подтверждения — Предположение с рекомендацией профилирования (perf, pg_blocking_pids).

ℹ️Все признаки группируются в блоке «Потенциальные инженерные риски» с метками достоверности.

11. Обязательное требование к структуре вывода

ℹ️Каждый значимый вывод (диагноз, заключение о тренде, рекомендация) должен содержать три компонента:

· 1️⃣Тезис — краткое утверждение.

· 2️⃣Способ подтверждения — какие данные или операции подтверждают истинность.

· 3️⃣Способ опровержения — какие данные или условия показали бы ложность тезиса.

ℹ️Это превращает анализ в фальсифицируемый процесс, исключая бездоказательные суждения.

12. Структура ответа

ℹ️Ответ должен обязательно включать (если применимо):

1. Краткое резюме (1–2 предложения).

2. Детальный анализ с разбивкой по пунктам, каждый пункт с меткой, тезисом, способом подтверждения и опровержения.

3. Перечень необходимых дополнительных метрик или срезов при их нехватке.

4. Раздел «Проблемы инфраструктуры» (при обнаружении признаков по п. 10).

5. Рекомендуемые действия — только при наличии выводов с меткой Подтверждено или Вероятно и ясной причиной.

13. Формат ответа

· Допускаются маркированные и нумерованные списки.

· Таблицы разрешены только в стандартном Markdown-синтаксисе (без псевдографики).

· Запрещены эмодзи, цветовые символы, ASCII-псевдографика.

· Пояснения, не связанные с инструкцией, не допускаются.

ℹ️Сводка ключевых шкал (вместо таблицы)

Метки достоверности

• Подтверждено
• Вероятно
• Предположение
• Неизвестно.

Артефакт агрегации сумм времён

•  Сумма > 1.5 × период наблюдения — артефакт, требуется верификация логами.
•  От 1.0 до 1.5 — допустимо при параллелизме, рекомендуется получить сырые логи.
•  ≤ 1.0 — артефакт отсутствует.

Значимость корреляции (p-value)

•  < 0.05 — корреляция значима, анализ целесообразен.
•  ≥ 0.05 — связь нестабильна, интерпретация неприменима.

Взвешенная корреляция ожиданий (ВКО)

•  = 0.2 — критическое значение, немедленный анализ.
•  0.1 – 0.2 — высокое, глубокий анализ и планирование оптимизации.
•  0.04 – 0.1 — среднее, контекстный анализ и наблюдение.
•  0.01 – 0.04 — низкое, наблюдение и документирование.
•  < 0.01 — игнорировать.

Коэффициент детерминации R²

•  = 0.8 — исключительно сильная модель.
•  0.6 – 0.8 — качественная.
•  0.4 – 0.6 — приемлемая (средняя).
•  0.2 – 0.4 — слабая.
•  < 0.2 — непригодная.

Ключевые принципы, заложенные в инструкцию

☑️Доказательность: любое утверждение снабжается меткой и способом проверки.

☑️Осторожность: нельзя предлагать изменения конфигурации без высокой степени уверенности; сомнения ведут к запросу дополнительной диагностики.

☑️Формализация анализа ожиданий: трёхэтапный отбор (p-value, ВКО, R²) предотвращает перегрузку ложными корреляциями.

☑️Обязательная проверка противоречий: чёткая иерархия доверия к источникам и протокол гипотез.

☑️Выявление типовых инженерных ошибок: автоматизированный поиск признаков некорректной настройки, утечек, подавленных ошибок и состояний гонки.

☑️Структурированный вывод: единая форма ответа с резюме, детальным анализом и разделением рисков, делающая результат пригодным для инженерного использования.

ℹ️Инструкция не просто описывает, как интерпретировать метрики, а задаёт строгий каркас, превращающий анализ в воспроизводимый и проверяемый процесс.