PG_EXPECTO 8.1.2 : Сравнительное влияние фальсифицируемости промптов на качество аналитических отчетов по производительности PostgreSQL

Экспериментальное сравнение директивного и фальсифицируемого промптов при анализе метрик производительности PostgreSQL 15.15: влияние требования предоставления опровергающей информации на глубину выводов, полноту рекомендаций и верифицируемость результатов.

Не утверждай — проверяй. Не советуй — опровергай.

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

Philosophical_instruction_BETA_v5.1.md - Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.

Предисловие

В современных исследованиях производительности СУБД всё более актуальной становится задача не только выявления узких мест, но и обеспечения проверяемости диагностических гипотез. Традиционный подход к анализу эксплуатационных логов и статистик часто опирается на авторитет эксперта, тогда как внедрение принципов фальсифицируемости (по К. Попперу) в процедуру генерации отчётов позволяет перейти от утвердительных выводов к системе экспериментально проверяемых утверждений.

В данной работе рассматривается случай использования двух версий промпта для анализа инцидента СУБД PostgreSQL. Единственное различие между версиями заключалось в требовании для каждого вывода указывать информацию, способную его опровергнуть.

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

Аналитический отчет подготовленный с помощью инструкции 8.1.1

Инструкция 8.1.2

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

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

Правила:

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

- При подготовке ответа с использованием "Philosophical_instruction_BETA_v5.1.md" заменяй цветовые символы на соответствующие им текстовые сокращения:

"Подтверждено"

"Вероятно"

"Предположение"

"Неизвестно"

- Для каждого вывода предоставь последовательность тезисов и требуемую информацию для опровержения

Задача:

Проанализируй отчет performance.txt

Подготовь итоговый отчет и рекомендации.

Состав отчета:

# Общая информация

# Ключевые проблемы СУБД и инфраструктуры

# Рекомендации по оптимизации СУБД и инфраструктуры.

# Необходимая дополнительная информация для продолжения анализа и оптимизации производительности СУБД и инфраструктуры

Общая информация

Периоды анализа

Тест: 2026-04-29 12:12 – 13:12

Инцидент: 2026-04-29 13:12 – 14:12

Конфигурация

• СУБД: PostgreSQL 15.15 на 16 vCPU (Intel Xeon Skylake, KVM), 62.79 ГБ ОЗУ.
• Диски: /data (vdb) 950 ГБ – таблицы/индексы; /wal (vdc) 95 ГБ – WAL.
• Ключевые параметры: shared_buffers = 16 ГБ, effective_cache_size = 48 ГБ, work_mem = 8 МБ, effective_io_concurrency = 300, checkpoint_timeout = 15 мин.

Интегральная картина

• Операционная скорость (SPEED) снизилась на ~8 % (с 387 тыс. до 358 тыс. в медиане), при этом суммарные ожидания (WAITINGS) немного уменьшились.
• В инциденте корреляция «ожидания – скорость» сменила знак: рост ожиданий стал приводить к падению скорости (отрицательная регрессия), тогда как в тесте такой зависимости не было.
• Доминирующий тип ожиданий: IO:DataFileRead – 99,7–99,9 % всех ожиданий.
• Формальные метрики ОС (утилизация CPU, очереди, %IO wait) не показывают перегрузки; загрузка дисков низкая (util < 13 %, r_await < 1 мс).

Ключевые проблемы СУБД и инфраструктуры

Каждая проблема сопровождается тезисом (статусом уверенности) и перечнем данных, которые могли бы опровергнуть данный вывод.

Проблема 1. Скрытое ограничение пропускной способности дисковой подсистемы (Уровень-1)

❓Тезис (Вероятно):

В инциденте - производительность PostgreSQL стала жёстко лимитироваться пропускной способностью дисков (MBps), а не IOPS или задержкой. Это особенно выражено для WAL-устройства (vdc) и в меньшей степени для данных (vdb). Корреляция SPEED ↔ MBps составила r=0,90 (vdc) и r=0,86 (vdb) с высоким R², тогда как в тесте связь была слабой.

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

• SPEED стал сильно отрицательно коррелировать с объёмом записываемых/читаемых данных (раздел 2.1.4).
• Корреляция cache ↔ wMBps усилилась в инциденте (до r=0,90–0,96), указывая на активное вытеснение страниц кэша при росте интенсивности записи.
• Утилизация устройств оставалась низкой (≈8–12 %), а времена отклика – небольшим (<4 мс). Такое сочетание характерно для ограничения на уровне гипервизора, QoS хранилища или burst-нагрузки, исчерпывающей доступную полосу.

Что может опровергнуть:

• Инструментальное тестирование (fio) покажет, что реальная доступная пропускная способность томов значительно выше наблюдаемой в нагрузке, а падение SPEED воспроизводится только при определённых паттернах доступа (например, случайное чтение).
• При отключении effective_io_concurrency или его снижении до 2 корреляция с MBps исчезнет, а скорость восстановится – тогда причина в избыточной конкурентности операций ввода-вывода, а не в физической полосе.
• Анализ со стороны СХД/гипервизора не выявит активных ограничений (QoS), а график потребления полосы в облаке покажет ровный профиль без насыщения.

Проблема 2. Хронический дефицит свободной оперативной памяти (Уровень-1)

☑️Тезис (Подтверждено):

На протяжении обоих периодов свободная память (free) без учёта кэша составляла менее 5 % (медиана ≈1 ГБ из 62,8 ГБ). Система не использует своп, но находится в состоянии, уязвимом для резких запросов памяти (OOM‑риск).

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

• free < 5 % в 100 % измерений, подтверждено метриками vmstat.
• Страничный кэш ОС (memory_cache) стабильно ~47,9 ГБ, что почти равно effective_cache_size. Это означает, что ОС заняла практически всю доступную память под файловый кэш, не оставляя резерва.

Что может опровергнуть:

• Увеличение vm.min_free_kbytes до 2–4 ГБ не меняет поведение кэша и не предотвращает внезапное падение производительности – тогда проблема глубже (например, фрагментация памяти).
• Анализ /proc/meminfo показывает, что большая часть памяти находится в SReclaimable, а не в Cached, и фактически может быть быстро возвращена – тогда дефицит не критичен.

Проблема 3. Неоптимальные параметры памяти СУБД (Уровень-2)

❓Тезис (Вероятно):

work_mem = 8 МБ на фоне 16 активных соединений и отсутствия temp_files в отчёте может приводить к излишним дисковым операциям (сортировкам или хеш-таблицам на диске).

Признаки:

• доминирование DataFileRead и нагрузка на ввод-вывод, но отсутствие прямых данных о временных файлах.

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

• work_mem определяет объём памяти для сортировок и хеш-таблиц на одну операцию в рамках одного запроса. При 8 МБ даже умеренные объёмы данных могут вытесняться на диск.
• DataFileRead доминирует, но без включённого log_temp_files невозможно подтвердить или опровергнуть дисковые сортировки.

Что может опровергнуть:

• Включение log_temp_files = 32MB и повторный мониторинг покажут отсутствие временных файлов или их минимальный размер – тогда work_mem достаточен.
• Увеличение work_mem до 32–64 МБ не снизит объём DataFileRead и не изменит корреляцию с IO – эффект незначителен.

Проблема 4. Избыточная конкуренция ввода-вывода (Уровень-3)

❔Тезис (Предположение):

effective_io_concurrency = 300 при фактической глубине очереди устройств <1 (aqu_sz ~0.1–0.8) не даёт выигрыша и может создавать лишние переключения контекста, косвенно подтверждаемые ростом корреляции cs ↔ sy в инциденте.

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

• Параметр предписывает PostgreSQL пытаться выдавать до 300 параллельных запросов к одному устройству, хотя реальная очередь практически отсутствует.
• В инциденте появилась значимая корреляция переключений контекста (cs) с системным временем (sy), что может указывать на дополнительные накладные расходы на планирование IO.

Что может опровергнуть:

• Снижение effective_io_concurrency до 2 не изменит ни количество переключений контекста, ни корреляцию с sy.
• Профилирование ядра (perf top) не покажет заметного времени в спинлоках или функциях планировщика, связанных с асинхронным IO.

Проблема 5. Недостаточная оптимизация запросов, доминирующих по IO (Уровень-2)

❓Тезис (Вероятно):

Нагрузка формируется несколькими запросами (особо выделяются queryid -3044179676593693136, показавший рост в инциденте, и 609930265604201774 с ростом в 1,9 раза), которые генерируют массовое чтение (DataFileRead). Вероятно, присутствуют Seq Scan по большим таблицам, не обеспеченные индексами.

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

• Топ-6 запросов формируют >50 % всех IO-ожиданий.
• Без анализа планов выполнения это – предположение, но типичная картина для DataFileRead без сопутствующих DataFilePrefetch.

Что может опровергнуть:

• EXPLAIN (ANALYZE, BUFFERS) для этих запросов покажет исключительно Index Scan с высокой долей попадания в кэш – тогда IO порождается не отсутствием индексов, а объёмом данных.

Рекомендации по оптимизации СУБД и инфраструктуры

Рекомендации сгруппированы по приоритетам и снабжены опровергающими условиями.

Первоочередные действия (Уровень-1)

Диагностика реальной пропускной способности дисковой подсистемы

• Действие (Подтвержденная необходимость): Провести нагрузочное тестирование fio с профилями случайной/последовательной записи блоками 8k и 1M на томах /data и /wal с глубиной очереди 1–32. Сравнить с наблюдаемыми объёмами в инциденте.
• Цель: Подтвердить или исключить скрытое ограничение полосы.
• Опровержение рекомендации: Если тест покажет полосу выше пиковых значений инцидента, то искать причину в другом.

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

• Действие (Вероятно эффективно): Получить планы выполнения (EXPLAIN (ANALYZE, BUFFERS)) для шести лидирующих queryid. Убедиться в отсутствии избыточных Seq Scan; добавить индексы там, где это оправдано.
• Цель: Снизить объём DataFileRead.
• Опровержение: Если планы покажут оптимальные индексные доступы, а объём чтения определяется размером индекса/таблицы, то необходима оптимизация на уровне приложения.

Обеспечение резерва свободной памяти

• Действие (Подтвержденная необходимость): Добавить 2–4 ГБ ОЗУ виртуальной машине, либо увеличить vm.min_free_kbytes до 3–5 ГБ для гарантии критического резерва.
• Цель: Исключить OOM‑риск и стабилизировать страничный кэш.
• Опровержение: Если мониторинг показывает, что пиковое потребление памяти не превышает 60 ГБ, а кэш стабильно восстанавливается без фрагментации, то срочность снижается.

Второстепенные действия (Уровень-2)

Повышение work_mem

• Действие (Вероятно полезно): Пошагово увеличить work_mem с 8 до 32 МБ (затем до 64 МБ), предварительно включив log_temp_files = 32MB. Мониторить появление/исчезновение временных файлов и изменение IO-ожиданий.
• Опровержение: Если при увеличении work_mem не снижается DataFileRead и не появляется выигрыша в скорости, параметр вернуть на исходное значение.

Тюнинг effective_io_concurrency

• Действие (Предположительно эффективно): Уменьшить effective_io_concurrency до 2 (или до числа фактических шпинделей, если используется HDD). На SSD‑дисках в среде виртуализации значение > 1 редко оправдано.
• Опровержение: Если после изменения корреляция cs↔sy не снижается и время отклика не улучшается – вернуть прежнее значение.

➡️Включение диагностических журналов

• Действие (Подтвержденная необходимость): Установить log_temp_files = 32MB, log_checkpoints = on, log_autovacuum_min_duration = 1s. Анализировать журнал на частые чекпойнты или аварийные сообщения.
• Цель: Выявить скрытые ошибки и деградацию.
• Опровержение: Не применимо – это мониторинг.

Действия уровня инфраструктуры (Уровень-2)

Ревизия размещения WAL

• Действие (Предположительно эффективно): При подтверждённом лимите пропускной способности vdc рассмотреть перенос WAL на отдельный быстрый NVMe‑том или увеличение числа дисков в группе.
• Опровержение: Если fio‑тест не выявит узкого места, действие отложить.

Профилирование ядра во время нагрузки

• Действие (Предположительно полезно): perf top -e cpu-clock или аналоги, сфокусированные на функциях ядра, отвечающих за планирование и IO. Выявить горячие спинлоки при росте cs↔sy.
• Цель: Подтвердить или исключить гонки на уровне ОС.

Необходимая дополнительная информация для продолжения анализа и оптимизации производительности

• Планы выполнения для шести наиболее ресурсозатратных запросов (queryid) с EXPLAIN (ANALYZE, BUFFERS, VERBOSE) – для оценки эффективности индексов и реальных источников чтения.
• Результаты тестирования fio на томах /data и /wal с указанными профилями – для подтверждения/опровержения дискового узкого места.
• Логи PostgreSQL за инцидентный период с включёнными log_temp_files, log_checkpoints, log_autovacuum_min_duration – для выявления скрытых предупреждений и временных файлов.
• ‼️Детальная статистика по temp_files и sorts из pg_stat_database за оба периода (в отчёте отсутствует) – для оценки влияния work_mem.
• Графики потребления пропускной способности и IOPS на уровне гипервизора/СХД за инцидент – для выявления внешних ограничений.
• Профиль ядра (perf top) за 5–10 минут под нагрузкой, аналогичной инциденту – для анализа роста системного времени и переключений контекста.

Без этих данных дальнейшая настройка параметров будет опираться на предположения («Предположение») и может не дать устойчивого эффекта.

Сравнительный анализ аналитических отчетов 8.1.1 - 8.1.2

Входные данные:

_incident_philosophical_instruction_prompt-1.txt - Промпт для подготовки аналитического отчета (Версия-1)

_incident_philosophical_instruction_prompt-2.txt - Промпт для подготовки аналитического отчета (Версия-2)

analyze-1.txt - аналитический отчет , подготовленный с помощью промпта "_incident_philosophical_instruction_prompt-1.txt"

analyze-2.txt - аналитический отчет , подготовленный с помощью промпта "_incident_philosophical_instruction_prompt-2.txt"

_pg_expecto_instruction.txt - доменная инструкция , использованная при подготовке аналитического отчета

Philosophical_instruction_BETA_v5.1.md - философская инструкция , использованная при подготовке аналитического отчета

Задача:

- Провести сравнительный семантический анализ промптов "_incident_philosophical_instruction_prompt-1.txt " и "_incident_philosophical_instruction_prompt-2.txt "

- Провести сравнительный семантический анализ аналитических отчетов "analyze-1.txt" и "analyze-2.txt"

- Сформировать вывод о влиянии промпта на полноту и качество аналитического отчета

Проведу сравнительный семантический анализ предоставленных промптов и отчетов в соответствии с инструкциями _pg_expecto_instruction.txt и Philosophical_instruction_BETA_v5.1.md.

Структура ответа:

1. Сравнительный семантический анализ промптов.
2. Сравнительный семантический анализ отчетов.
3. Вывод о влиянии промпта на полноту и качество отчета.

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

Оба промпта (_incident_philosophical_instruction_prompt-1.txt и ...-2.txt) имеют общее семантическое ядро, определяющее роль, задачу и базовые правила, но кардинально расходятся в одном ключевом аспекте.

Общее семантическое ядро:

• Роль: Эксперт по производительности СУБД PostgreSQL.
• Задача: Анализ отчета performance.txt на основе двух инструкций, с заменой цветовых символов на текстовые метки (Подтверждено, Вероятно, Предположение, Неизвестно).
• Целевая структура отчета: # Общая информация, # Ключевые проблемы, # Рекомендации, # Необходимая дополнительная информация.

Ключевое семантическое различие:

Единственное, но фундаментальное различие находится в версии 2 (_incident_philosophical_instruction_prompt-2.txt) и выражено в дополнительном правиле:

- Для каждого вывода предоставь последовательность тезисов и требуемую информацию для опровержения

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

• Версия 1 формирует директивный, утвердительный отчет. Аналитик представляет свои выводы как данность. Такой отчет отвечает на вопрос "Что произошло и что делать?".
• Версия 2 формирует научно-обоснованный, фальсифицируемый отчет. Требование предоставить "информацию для опровержения" напрямую вытекает из принципов фальсифицируемости (Блок 3.2, Philosophical_instruction_BETA_v5.1.md) и методики _pg_expecto_instruction.txt (уровни доказательности "Вероятно", "Предположение"). Аналитик не просто делает вывод, но и заранее определяет, что может его опровергнуть. Это превращает вывод из утверждения в проверяемую гипотезу. Такой отчет отвечает на вопрос "Какова наша лучшая гипотеза на данный момент, и как мы узнаем, что ошибались?".

2. Сравнительный семантический анализ отчетов

Анализ отчетов analyze-1.txt и analyze-2.txt полностью подтверждает влияние, заложенное на уровне промптов. Ниже каждый ключевой аспект анализа рассмотрен для обоих документов.

Характер выводов

• analyze-1.txt: Выводы носят утвердительный, констатирующий характер. Проблемы перечисляются как факты: «Доминирующие ожидания... (подтверждено)», «Острый дефицит... (вероятно)». Это маркировка уровня уверенности, но не фальсифицируемость.
• analyze-2.txt: Выводы имеют исследовательский, гипотетический характер. Каждая проблема — это проверяемый тезис. Даже статус «Подтверждено» не является окончательным. В обязательном порядке введены блоки «Что может опровергнуть:» и «Опровержение рекомендации:».

Глубина анализа

• analyze-1.txt: Анализ сфокусирован на симптомах (ожидания, использование памяти) и прямых причинах (конкретные запросы, параметры конфигурации shared_buffers, work_mem).
• analyze-2.txt: Анализ глубже на один уровень. Он не только указывает на DataFileRead, но и выдвигает первопричинную гипотезу: скрытое ограничение пропускной способности дисковой подсистемы, а не просто «ожидания ввода-вывода». Идет поиск системных ограничений (гипервизор, QoS).

Рекомендации

• analyze-1.txt: Рекомендации даны в формате прямых советов («снизить до 2–3 ГБ», «увеличить до 16–32 МБ»). Они обоснованы, но не верифицируемы в рамках самого отчета.
• analyze-2.txt: Рекомендации сгруппированы по уровням и содержат встроенный механизм проверки эффективности («Если тест покажет полосу выше... искать причину в другом», «Если при увеличении work_mem не снижается DataFileRead... вернуть»). Это превращает выполнение рекомендаций в научный эксперимент.

Запрос дополнительной информации

• analyze-1.txt: Запрашиваются стандартные данные: планы запросов, настройки, статистика temp_files.
• analyze-2.txt: Помимо стандартных, запрашиваются верифицирующие данные: результаты fio-тестов (для проверки гипотезы о пропускной способности), данные с гипервизора/СХД, профиль ядра (perf top). Запрос информации напрямую связан с условиями опровержения выдвинутых гипотез.

Соответствие инструкциям

• analyze-1.txt: Соответствует _pg_expecto_instruction.txt в части анализа метрик и Philosophical_instruction_BETA_v5.1.md в части маркировки уверенности.
• analyze-2.txt: Полностью реализует принципы обеих инструкций, особенно углубленный уровень _pg_expecto_instruction.txt (Раздел 4: Race conditions, Resource leaks, Copy-paste without understanding) и философские принципы фальсифицируемости и честности.

3. Вывод о влиянии промпта на полноту и качество аналитического отчета

☑️Влияние промпта является определяющим. Промпт версии 2, содержащий требование «информации для опровержения», привел к созданию качественно иного, превосходящего по эпистемической строгости и практической ценности отчета.

• Вероятно, отчет по Промпту-1 (analyze-1.txt) воспринимается как более простой и готовый к немедленным действиям, но его рекомендации основаны на авторитете эксперта, а не на прозрачной цепочке доказательств. Он хорош для быстрого реагирования на инцидент, но несет риск выполнения неоптимальных действий, если первопричина была определена неверно.
• Подтверждено, что отчет по Промпту-2 (analyze-2.txt) обладает большей полнотой, так как не только описывает проблему, но и создает карту ее верификации и опровержения.
• Качество и надежность выводов значительно выше. Пользователь получает не просто ответ, а инструмент для проверки этого ответа. Это напрямую реализует стандарты эпистемической честности (из Philosophical_instruction_BETA_v5.1.md): «Act so that the maxim of your action could become a universal law» и «Report everything that weakens the conclusion — especially if it undermines your position».
• Такой подход снижает риск выполнения ложных рекомендаций, так как каждое действие по оптимизации имеет четкий критерий успешности и условие отката. Это переводит процесс оптимизации из области «экспертного совета» в область «экспериментальной проверки гипотез», что является сутью научного метода (Блок 3, Philosophical_instruction_BETA_v5.1.md).

Итог:

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

Общий технический итог

Проведённый семантический и структурный анализ двух отчётов (analyze-1.txt, сформированный по промпту без требования опровержения, и analyze-2.txt, сформированный по промпту с требованием опровержения) выявил следующие различия.

Отчёт версии 1 носит директивный характер: проблемы перечислены как факты с метками уверенности («Подтверждено», «Вероятно»), рекомендации даны в форме прямых советов, а запрос дополнительной информации ограничен стандартными данными (планы запросов, настройки, статистика temp_files).

Отчёт версии 2, напротив, представляет каждую проблему в виде проверяемого тезиса, сопровождаемого блоком «Что может опровергнуть», включает в рекомендации условия отката и верификации эффективности («Если тест покажет полосу выше… искать причину в другом»), а также запрашивает специфические инструментальные данные (результаты fio-тестов, профили ядра, метрики гипервизора).

Ключевым техническим следствием является то, что отчёт версии 2 позволяет не только интерпретировать инцидент, но и экспериментально подтвердить или опровергнуть каждую выдвинутую гипотезу до выполнения изменений конфигурации.

Тем самым повышается надёжность последующих оптимизационных действий и снижается риск внесения неэффективных или деструктивных настроек.

Послесловие

Представленные результаты имеют ограничения, связанные с единичным случаем инцидента и использованием конкретной доменной инструкции (_pg_expecto_instruction.txt) и философского ядра BETA_v5.1. Обобщение выводов требует повторения эксперимента на других типах нагрузок (OLTP, аналитические запросы, смешанные сценарии) .

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

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