PG_EXPECTO + Philosophical_instruction 5.1 = повышение качества анализа инцидентов PostgreSQL

Как двухуровневая система инструкций — предметная PG_EXPECTO и эпистемическая Philosophical_instruction — превращает описание симптомов в верифицируемый план действий и устраняет иллюзию полного знания при диагностике PostgreSQL.

Пропускаем хаос метрик через призму эпистемической честности.

Max: PG_EXPECTO

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

GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

Предыдущая статья цикла - причины выбора инструкции 5.1:

Предисловие

В практике расследования инцидентов производительности PostgreSQL часто возникает разрыв между обилием собранных метрик и способностью аналитика превратить их в достоверный план действий без риска ложных корреляций и поспешных выводов. Настоящий материал представляет сравнительный семантический анализ двух методологически разных подходов к формированию диагностических отчетов: базового, опирающегося на традиционную интерпретацию агрегированных данных, и подхода, реализованного в рамках комплекса PG_EXPECTO с применением Philosophical_instruction версии 5.1.

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

Дополнительные материалы для статьи :

Обоснование выбора версии 5.1 философской инструкции:

Итоговый вердикт: инструкция v5.1 обеспечивает наивысшую достоверность выводов, однако ее эффективность находится в прямой зависимости от полноты предоставленных доменных критериев и первичных временных рядов.

Задача

Провести сравнительный анализ влияния методологии PG_EXPECTO + Philosophical_instruction на качество анализа инцидента производительности СУБД, по сравнению с базовой методикой pg_expecto, при анализе инцидента производительности СУБД:

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

Анализ различий между отчётом по инциденту производительности СУБД, созданным с помощью инструкции PF_EXPECTO, и базовым отчётом

Промпт

Ты — эксперт по производительности СУБД PostgreSQL.

Твоя задача — анализировать статистические данные (метрики, логи, статистические обработанные метрики производительности СУБД и инфраструктуры выводы) и давать точный, предметный анализ результатов.

Правила:

Для подготовки ответов используй инструкцию "Philosophical_instruction_BETA_v5.1.md"

Задача:

#1. Провести семантический анализ отчетов "base-incident.txt" и "5.1.incident.txt"

#1.1 Проанализировать и сформулировать последствия использования инструкции "инструкция_pg_expecto.txt" и промпта "5.1.incident-prompt.txt" на полноту и качество отчета "5.1.incident.txt" по сравнению с "base-incident.txt" и промптом "base-prompt.txt"

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

Шаг-1 : Загрузить инструкции

Шаг-2 : Подготовить отчет

Краткое резюме

🟢 Отчет 5.1.incident.txt, подготовленный по специализированной инструкции инструкция_pg_expecto.txt и промпту 5.1.incident-prompt.txt, демонстрирует существенно более высокую полноту и аналитическую глубину по сравнению с base-incident.txt, сформированным по общему промпту base-prompt.txt.

Основные улучшения: добавление детального анализа дисковой подсистемы (iostat), расширенная интерпретация корреляций, проверка согласованности метрик, выявление артефактов агрегации и явное указание границ применимости данных. Качество анализа повышено за счёт обязательного структурирования выводов, профессиональной терминологии и критического подхода к интерпретации статистических связей.

🔴 В то же время в 5.1.incident.txt сохранены некоторые элементы, противоречащие собственной инструкции (использование таблиц в исходном файле отчёта), а также присутствуют рекомендации, выходящие за рамки допустимого в инструкции (явное предложение изменить параметры конфигурации).

🟡 Общая рекомендация: при проведении подобных анализов следует придерживаться подхода, реализованного в 5.1.incident.txt, но с более строгим соблюдением ограничений на формулирование рекомендаций и формат вывода.

1. Семантический анализ отчетов

1.1. Полнота и глубина анализа (сравнение base-incident.txt и 5.1.incident.txt)

• Источники данных
• base-incident.txt: только агрегированные метрики СУБД и vmstat (_2.postgresql_vmstat.txt, _2.1.test.postgresql_vmstat.txt).
• 5.1.incident.txt: дополнительно включены данные дисковой подсистемы (_3.vmstat_iostat.txt, _3.1.test.vmstat_iostat.txt) и файл конфигурации СУБД (_1.settings.txt).
• 🟢 В 5.1 анализ подкреплён критически важными для диагностики данными о дисковой подсистеме и настройках.
• Анализ ожиданий СУБД
• base-incident.txt: анализ по типам ожиданий (Extension, LWLock, IO, Lock) с ВКО и R².
• 5.1.incident.txt: аналогичный анализ, дополненный интегральными приоритетами, более детальной разбивкой по конкретным событиям (BufferMapping, WALWrite, WALSync, tuple).
• 🟢 5.1 даёт более тонкую картину изменения структуры ожиданий.
• Анализ vmstat
• base-incident.txt: рассмотрены тренды r, b, wa, id.
• 5.1.incident.txt: дополнительно приведены медианные значения, явно отмечены несоответствия (например, снижение b при росте iowait).
• 🟢 5.1 прямо указывает на внутреннюю несогласованность метрик, что соответствует требованию инструкции pg_expecto.
• Анализ дисковой подсистемы (iostat)
• base-incident.txt: отсутствует.
• 5.1.incident.txt: подробный раздел 2, включающий граничные значения, корреляции wa~util, buff/cache с операциями ввода-вывода, связь операционной скорости с пропускной способностью дисков.
• 🟢 Ключевое преимущество 5.1. Без этого раздела невозможно подтвердить гипотезу о дисковом узком месте, которая в base-incident остаётся лишь предположением.
• Анализ запросов (queryid)
• base-incident.txt: указаны лидирующие запросы и изменение их долей.
• 5.1.incident.txt: более чётко выделен аномальный запрос -5038981907002478858, показано его влияние на разные типы ожиданий.
• 🟢 5.1 конкретизирует объект для первоочередной оптимизации.
• Проверка согласованности метрик
• base-incident.txt: отсутствует.
• 5.1.incident.txt: присутствует (отмечено, что высокая доля IPC является математическим следствием и не должна интерпретироваться как критический фактор; проверено соотношение free RAM и cache).
• 🟢 Прямое следование инструкции pg_expecto (требование не делать ложных выводов из математически зависимых метрик).
• Указание границ применимости данных
• base-incident.txt: отсутствует.
• 5.1.incident.txt: явно перечислены недостающие данные (планы запросов, тексты SQL, детализация по CPU), ограничивающие глубину выводов.
• 🟢 Соответствует требованию инструкции «явно указывать границы применимости данных».
• Рекомендации
• base-incident.txt: в явном виде отсутствуют, представлены только «Ключевые проблемы».
• 5.1.incident.txt: присутствуют (раздел 4), сгруппированы по СУБД и инфраструктуре, сформулированы как направления для дальнейшей диагностики.
• 🟡 Полезно для практического применения, но в инструкции pg_expecto содержится запрет на предложение изменений конфигурации при сомнениях. В 5.1 встречаются фразы типа «рассмотреть увеличение shared_buffers», что формально нарушает это ограничение.
• Форматирование
• base-incident.txt: преимущественно текст с абзацами.
• 5.1.incident.txt: структурировано по разделам с подзаголовками, но внутри разделов также используется текст. В исходном файле отчёта присутствуют таблицы, хотя инструкция pg_expecto требует «только списки».
• 🟡 Неполное соответствие формальному требованию к формату вывода.

1.2. Влияние инструкции инструкция_pg_expecto.txt и промпта 5.1.incident-prompt.txt

• Положительные последствия:
• Принудительная детализация. Требование анализировать конкретные метрики (iostat, настройки) обусловило включение в отчёт разделов, пропущенных в base-incident. Это позволило обнаружить прямую корреляцию операционной скорости с записью на диск (R²=0.54) — ключевой диагностический вывод.
• Критичность мышления. Инструкция обязывает проверять внутреннюю согласованность и избегать ложных корреляций. В 5.1 это проявилось в комментариях о неинформативности высокой доли IPC и в осторожной интерпретации связи buff с чтением/записью.
• Профессиональная точность. Использование точной терминологии (LWLock:BufferMapping, WALSync, tuple lock) и ссылка на конкретные параметры конфигурации (shared_buffers, effective_cache_size) повышает практическую ценность отчёта для администратора PostgreSQL.
• Структурирование выводов. Чёткое разделение на «Проблемы СУБД» и «Проблемы инфраструктуры» упрощает планирование дальнейших действий.
• Отрицательные последствия / Недостатки:
• Игнорирование формального запрета на таблицы. В исходном тексте 5.1.incident.txt для представления граничных значений и корреляций используются таблицы, что прямо противоречит правилу «Даже если таблицы нагляднее — используй только списки». Это снижает строгость следования инструкции.
• Выход за рамки рекомендаций. Инструкция предписывает «не предлагать изменений конфигурации, если сомневаешься», а предлагать дополнительную диагностику. В отчёте присутствуют конкретные предложения типа «рассмотреть увеличение shared_buffers» или «рассмотреть увеличение числа буферных разделов через lwlock_shared_limit». Хотя они поданы как направления для тестирования, это всё же является предложением изменений, что в строгом смысле не разрешено инструкцией без дополнительных данных.
• Избыточность. Некоторые разделы (например, подробное перечисление корреляций для каждого дискового устройства) могут быть излишне детализированы для сводного отчёта, но это следствие требования «анализировать тренды, а не точечные значения» и предоставления полных данных.

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

🟢 Рекомендуется использовать подход, реализованный в 5.1.incident.txt, как базовый для последующих анализов производительности PostgreSQL.

Обоснование:

• Отчёт 5.1.incident.txt обеспечивает значительно более высокую диагностическую ценность за счёт включения данных дисковой подсистемы (iostat), проверки внутренней согласованности метрик и явного указания на недостающие данные. Это позволяет перейти от констатации факта деградации (base-incident) к выявлению конкретного узкого места (насыщение пропускной способности дисков данных и аномальная активность расширений у конкретного запроса).
• Специализированная инструкция инструкция_pg_expecto.txt успешно выполняет функцию методологического фильтра, отсеивающего поверхностные интерпретации и требующего подтверждения гипотез количественными данными.

🟡 Условия для повышения качества (на основе выявленных недостатков):

1. Строгое соблюдение формата вывода. При формировании финального ответа для пользователя все данные должны быть представлены исключительно в виде списков, без использования таблиц, даже если в исходных материалах они присутствуют.
2. Ограничение рекомендаций. Раздел с рекомендациями следует формулировать исключительно как перечень направлений для дальнейшей диагностики и сбора дополнительных данных, избегая любых предложений по изменению конкретных параметров конфигурации (например, shared_buffers, work_mem, lwlock_shared_limit), если только эти изменения не являются тривиальным исправлением очевидной ошибки конфигурации, подтверждённой документацией. Рекомендуемые формулировки: «Требуется провести анализ эффективности текущего значения shared_buffers на основе статистики pg_stat_bgwriter».
3. Дополнительная проверка артефактов агрегации. В будущих анализах следует ещё более явно отделять «математически ожидаемые» корреляции (например, рост общего объёма записи при росте количества транзакций) от «новых» значимых связей, как это было частично сделано для IPC.

🔴 Критическое замечание: Несмотря на высокое качество 5.1.incident.txt, недостаточно данных для окончательного заключения о первопричине. Отчёт верно указывает на следствия (насыщение дисков, рост LWLock), но для установления причины (изменившийся план запроса, рост числа транзакций, внешнее воздействие) необходимы запрошенные в отчёте дополнительные данные: планы выполнения, тексты запросов, логи СУБД. Любые действия по изменению конфигурации без этих данных несут риск неэффективного расходования ресурсов.

2. Анализ различий между базовым отчетом по инциденту производительности СУБД и сводным аналитическим отчетом , подготовленным с помощью Philosophical_instruction.

Инструкции загружены на предыдущих шагах.

Шаг-3 : Подготовить анализ

Семантический анализ отчетов

Сравнение base-incident.txt (промпт base-prompt.txt) и 5.1.Philosophical_instruction.txt (промпт 5.1.analyze-prompt.txt + инструкции инструкция_pg_expecto.txt и Philosophical_instruction_BETA_v5.1.md) выявило существенные различия в методологии, структуре и практической ценности итогового анализа.

1. Сравнение полноты и качества отчетов

1.1. Источники и обработка данных

• base-incident.txt
• Использует агрегированные данные из двух файлов СУБД и vmstat.
• Отсутствует анализ конфигурации PostgreSQL и детальных метрик дисковой подсистемы (iostat).
• Выводы строятся преимущественно на статистических корреляциях без проверки их математической обусловленности.
• 🟡 Данные представлены подробно, но без явной оценки достоверности каждого утверждения.
• 5.1.Philosophical_instruction.txt
• Опирается на те же исходные данные, но включает анализ настроек СУБД (_1.settings.txt) и iostat (через ранее обработанный отчет 5.1.incident.txt).
• 🟢 Явно разделяет факты (🟢), предположения (🟡) и зоны неопределенности (🔴).
• 🟢 Проверяет внутреннюю согласованность метрик (например, рост медианного cpu idle при отрицательном тренде) и указывает на противоречия.
• 🟢 Вводит раздел «Необходимая дополнительная информация», четко обозначая границы применимости текущего анализа.

1.2. Структура и фокус

• base-incident.txt
• Представляет собой детальный «сырой» отчет с множеством разделов: граничные значения, тренды, корреляции, Парето, детальный анализ.
• Содержит много числовых данных, но интерпретация часто носит описательный характер без выделения приоритетов.
• 🟡 Объемный, но пользователю сложно сразу выделить ключевые проблемы и требуемые действия.
• 5.1.Philosophical_instruction.txt
• Сфокусирован на ключевых проблемах и практических рекомендациях.
• 🟢 Каждый пункт проблем и рекомендаций маркирован уровнем уверенности (traffic light), что напрямую соответствует требованиям Philosophical_instruction_BETA_v5.1.md (эпистемическая честность).
• 🟢 Структура оптимизирована для принятия решений: «Что случилось» → «Что с этим делать» → «Чего не хватает для точного плана».

1.3. Эпистемическая честность и управление неопределенностью

• base-incident.txt
• Все выводы подаются в одинаково уверенном тоне, независимо от их доказательной базы.
• 🔴 Нет явного разделения между наблюдаемыми фактами, статистическими корреляциями и гипотезами.
• 🔴 Отсутствуют предупреждения о возможной ложной интерпретации корреляций (например, связь Extension и in подается как факт без оговорок о необходимости дополнительной проверки).
• 5.1.Philosophical_instruction.txt
• 🟢 Строгое следование принципу «трафик-светов»: факты, подтвержденные исходными метриками, помечены 🟢; логичные, но не подтвержденные напрямую выводы — 🟡; предположения и рекомендации, требующие проверки, — 🔴.
• 🟢 Явно указывает, что без дополнительных данных (планы запросов, логи) любые рекомендации по изменению параметров конфигурации являются спекулятивными (🔴).
• 🟢 Содержит раздел «Необходимая дополнительная информация» с ранжированием по критичности, что является прямым воплощением принципа «Недостаточно данных для ответа» из инструкция_pg_expecto.txt и требования указывать границы применимости.

1.4. Практическая ценность и действенность

• base-incident.txt
• Предоставляет много сырых данных, но не дает четкого направления для действий.
• 🟡 Администратору БД придется самостоятельно перерабатывать отчет для составления плана диагностики и оптимизации.
• 5.1.Philosophical_instruction.txt
• 🟢 Представляет собой готовый план первоочередных действий с явными приоритетами (🔴 приоритет для проблемы дисков и запроса -503898...).
• 🟢 Рекомендации сформулированы как конкретные шаги по диагностике (получить план запроса, проверить статистику pg_stat_bgwriter) и направления для оптимизации.
• 🟢 Четко отделяет проблемы СУБД от проблем инфраструктуры, что упрощает распределение ответственности.

2. Влияние инструкций инструкция_pg_expecto.txt и Philosophical_instruction_BETA_v5.1.md

Применение двухуровневой системы инструкций (специализированной предметной и общей эпистемической) привело к качественному скачку в аналитике:

• инструкция_pg_expecto.txt обеспечила:
• Фокус на конкретных метриках PostgreSQL и их интерпретации.
• Требование проверять внутреннюю согласованность и избегать артефактов агрегации (что привело к выявлению противоречия в данных cpu idle).
• Профессиональную терминологию и точность в описании проблем.
• Philosophical_instruction_BETA_v5.1.md добавила:
• Эпистемическую строгость: каждое утверждение получило оценку достоверности, что полностью исключает ложную уверенность.
• Структурирование неопределенности: явное перечисление того, что мы не знаем, и что нужно для устранения незнания.
• Этику информирования: пользователь получает не просто «красивый отчет», а честную картину с указанием всех «слабых мест» анализа.

Результат синергии:

Отчет 5.1.Philosophical_instruction.txt не просто описывает симптомы, а предоставляет верифицируемую и приоритизированную основу для принятия решений, соответствующую высшим стандартам научной честности (как того требует философская инструкция).

3. Итоговая рекомендация

🟢 Для проведения анализа производительности PostgreSQL и подготовки итоговых отчетов настоятельно рекомендуется использовать комбинированный подход, реализованный в 5.1.Philosophical_instruction.txt.

Обоснование:

• Полнота и точность: Подход гарантирует, что анализ опирается на проверяемые данные, явно указывает на ограничения и избегает ложных выводов.
• Практическая направленность: Итоговый документ сфокусирован на ключевых проблемах, содержит ранжированные рекомендации и четкий план дальнейшей диагностики, что экономит время специалистов.
• Управление рисками: Использование «трафик-светов» и явное указание на недостаток данных предотвращает принятие необоснованных или поспешных решений по изменению конфигурации продуктивных систем.

Ключевые компоненты успешного подхода для обязательного использования в будущем:

• 🟢 Двухуровневая система инструкций: Специализированная предметная инструкция (pg_expecto) для контекста и общая эпистемическая (Philosophical) для контроля качества мышления.
• 🟢 Маркировка достоверности (Traffic Lights): Обязательное применение 🟢🟡🔴⬛ к каждому значимому утверждению.
• 🟢 Раздел «Необходимая дополнительная информация»: Структурированный список недостающих данных с указанием их критичности.
• 🟢 Разделение выводов и рекомендаций: Четкое отделение констатации проблем от предлагаемых действий, причем последние всегда сопровождаются указанием на необходимость проверки в конкретной среде.

🔴 Категорически не рекомендуется использовать подход base-incident.txt для финальной коммуникации с заказчиком или командой, так как он создает иллюзию полного знания там, где ее нет, и не дает четкого руководства к действию.

Послесловие

Проведенный анализ со всей определенностью показывает, что истинная ценность диагностического отчета измеряется не объемом представленных метрик, а строгостью методологии, стоящей за их интерпретацией. Комбинация инструментария PG_EXPECTO и принципов Philosophical_instruction демонстрирует переход от иллюстративного описания инцидента к эпистемически выверенному расследованию, где каждая гипотеза снабжена маркером достоверности, а каждый вывод сопровождается честным признанием границ собственной применимости. В условиях высокой цены ошибки для продуктивных систем PostgreSQL именно такой подход, ставящий во главу угла проверку внутренней согласованности данных и защиту от ложной интерпретации корреляций, должен стать новым профессиональным стандартом, позволяющим администратору не гадать о причинах деградации, а опираться на верифицируемый план первоочередных действий.