GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Philosophical_instruction_BETA_v5.1.md - Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.
Коллекция промптов для нейросети DeepSeek (на русском языке), предназначенных для анализа и оптимизации производительности СУБД PostgreSQL.
GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Предисловие
Анализ журналов работы СУБД PostgreSQL традиционно сопряжён с высокой трудоёмкостью ручного поиска аномалий, ошибок ресурсного обеспечения и неоптимальных параметров фоновых процессов (autovacuum, checkpoint). В условиях растущих требований к достоверности выводов и необходимости исключения субъективных искажений возникает потребность в инструментах, сочетающих статистические методы с элементами искусственного интеллекта, работающими в рамках формальной эпистемологии. Комплекс PG_EXPECTO версии 8.1.1, интегрированный с аналитическими промптами для нейросети DeepSeek, реализует научный метод обработки логов, включая встроенную самопроверку, процедуры «красного команды» (Red Teaming), анализ «смерти до вскрытия» (Pre-Mortem) и защиту от инъекций подсказок (prompt injection). Настоящая статья представляет результаты применения указанного подхода к структурному анализу журнала СУБД с выделением ключевых проблем производительности и инфраструктурных ограничений.
Генерация отчёта по нагрузочному тестированию с использованием DeepSeek
Дополнение в промпт , для формирования исходного статистического отчета
# 3. Анализ лога СУБД
## 3.1 Анализ по разделу "СТАТИСТИКА ПО ОШИБКАМ СУБД"
## 3.2 Анализ по разделу "СТАТИСТИКА ПО ПРОЦЕССУ autovacuum"
## 3.3 Анализ по разделу "СТАТИСТИКА ПО ПРОЦЕССУ checkpoint"
Результат - дополнения в аналитический отчет СУБД
Ключевые проблемы СУБД и инфраструктуры
Проблемы СУБД
...
4. Неоптимальные настройки autovacuum
(Предположение) Параметр autovacuum_vacuum_scale_factor = 0.2 оставлен по умолчанию. При потенциально больших таблицах (данные о размерах отсутствуют) это может приводить к накоплению мёртвых строк и неэффективной очистке. Статистика autovacuum показывает удаление всего 3 страниц за период при 294 операциях — косвенный признак, что порог срабатывания слишком высок.
5. Ошибка недостаточности ресурсов (insufficient_resources)
(Вероятно) Зафиксирован 1 случай ошибки. Без анализа журналов PostgreSQL невозможно установить причину (лимит соединений, нехватка памяти или иной ресурс). Требуется проверка.
6. Ошибки обращения к отсутствующим объектам (undefined_object)
(Подтверждено) Зафиксировано 2 случая. Могут указывать на проблемы целостности схемы данных или логики приложения. Требуется анализ логов.
...
Рекомендации по оптимизации СУБД и инфраструктуры
СУБД
...
3. Уточнение параметров autovacuum
Получить статистику pg_stat_user_tables (количество n_dead_tup, размер таблиц). Если обновляемые таблицы велики (десятки ГБ), уменьшить scale_factor до 0.05–0.1, чтобы очистка запускалась чаще. Без данных конкретные значения предлагать нельзя (Предположение).
При необходимости точечно настроить параметры для отдельных таблиц через ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = ...).
4. Включение протоколирования временных файлов
Установить log_temp_files = 0 для регистрации всех временных файлов. Это позволит оценить, достаточно ли текущего work_mem (32 МБ) или запросы вынужденно используют диск для сортировок/хеш-таблиц. (Подтверждено: метрика temp_files в предоставленных данных отсутствует; требуется её появление.)
5. Расследование ошибок
Проанализировать журналы PostgreSQL за период для выяснения контекста ошибок undefined_object и insufficient_resources. Для insufficient_resources проверить, не достигнут ли лимит max_connections (100) или не исчерпана ли память под work_mem.
...
Необходимая дополнительная информация для продолжения анализа и оптимизации производительности СУБД и инфраструктуры
...
- Журналы PostgreSQL: полные тексты ошибок и предупреждений за период наблюдения, особенно для insufficient_resources и undefined_object. Нужны для установления первопричины ошибок.
- Метрики временных файлов: temp_files и temp_bytes из pg_stat_database за тот же период, чтобы определить, не происходит ли избыточный сброс на диск из-за недостаточного work_mem.
...
Общий технический итог
В ходе применения PG_EXPECTO 8.1.1 к предоставленному журнальному следу PostgreSQL были выявлены следующие статистически значимые паттерны: зафиксированы единичные ошибки классов insufficient_resources (вероятное исчерпание лимита соединений или памяти) и undefined_object (нарушение целостности схемы данных или логики приложения); обнаружены косвенные признаки неоптимальной конфигурации autovacuum (294 операции очистки при удалении лишь 3 страниц, что указывает на завышенный порог срабатывания при значении autovacuum_vacuum_scale_factor = 0.2 по умолчанию); идентифицировано отсутствие протоколирования временных файлов (log_temp_files не установлен в 0), что исключает оценку эффективности work_mem. На основе полученных данных сгенерированы адресные рекомендации: уточнение параметров autovacuum с учётом статистики pg_stat_user_tables, включение регистрации временных файлов, а также углублённый анализ контекста ошибок по полным текстам журналов. Итоговый отчёт, формируемый комплексом, содержит строгое разделение на подтверждённые факты, предположения (требующие дополнительной информации) и действия по расследованию, что соответствует принципу максимальной правдивости и минимизации галлюцинаций.
Послесловие
Представленная методология PG_EXPECTO 8.1.1 демонстрирует эффективность симбиоза статистического анализа логов СУБД и формализованных механизмов ИИ-верификации. Полученные результаты, однако, не являются окончательным диагнозом: они формируют упорядоченный перечень гипотез и запросов на недостающие метрики (полные журналы ошибок, temp_files, pg_stat_user_tables). Дальнейшее развитие комплекса предполагает автоматическое извлечение контекстных данных из системных каталогов PostgreSQL и интеграцию с циклами непрерывной оптимизации производительности. Практическое применение PG_EXPECTO в рабочих средах подтверждает его ценность как инструмента, сокращающего время локализации проблем с часов до минут при условии сохранения итогового контроля со стороны инженера-эксперта.