PG Audit
12–17

Найдите, что тормозит вашу PostgreSQL — и проверьте, что исправили

Полный цикл аудита PostgreSQL: индексы, autovacuum, конфигурация, транзакции, надёжность. Сначала бесплатный чек в браузере — затем полный план с готовым remediation.sql за 30 000 ₽.

11
проблем найдено
2 → 0
Critical после SQL
5 / 0
исправлено / новых
Бесплатный чек PostgreSQLПосмотреть реальный отчёт «до / после» →
Данные не покидают браузерБез remote adminОдин JSON-файл
pg_audit@demo-host:~$
# Соединение — только чтение
conn.set_session(readonly=True,
                 autocommit=True)

# Что читает скрипт
 pg_stat_user_tables   # размер, сканирования
 pg_stat_user_indexes  # использование индексов
 pg_settings           # конфигурация
 pg_class              # структура объектов

# Что НЕ читает
✗ Содержимое ваших таблиц
✗ Пользовательские данные
✗ Пароли и тексты запросов

# Результат: один JSON-файл
# audit_data_20260710_144312.json

Реальный прогон на тестовом стенде

PostgreSQL 16.14, база pg_audit_test 207 МБ. Snapshot → отчёт → применение remediation.sql → новый snapshot → сравнение. Три файла — не имитация.

ДО

20260710_144312

Uptime 0.6h · PostgreSQL 16.14 · 207 MB

2
Crit
3
High
3
Med
1
Low
2
Info
  • Нет PK · pgbench_accounts (1M строк)
  • Autovacuum off · database-level
  • Dead tuples 51.7% · 516 957 / 1M
  • work_mem слишком мал

ПОСЛЕ

20260710_151304

Тот же стенд, через 18 минут после SQL

0
Crit
2
High
1
Med
1
Low
2
Info
Сравнение
5 исправлено · 0 новых проблем
  • ✓ Critical: PK восстановлен
  • ✓ Critical: autovacuum включён
  • ✓ High: dead tuples очищены
  • ✓ Medium: work_mem увеличен
  • ✓ Medium: log_min_duration_statement
Открыть отчёт «ДО»Открыть отчёт «ПОСЛЕ»Открыть сравнениеСкачать remediation.sql

Как это работает

Пять шагов от запуска Collector до проверки результата

  1. 1Запустите Collector

    Локально на сервере · snapshot за секунды

  2. 2Бесплатный чек

    Мгновенно в браузере — что обнаружено

  3. 3План оптимизации

    Полный отчёт + remediation.sql · 30 000 ₽

  4. 4Примените SQL

    Сначала staging → потом production

  5. 5Repeat Check

    Доказательство результата · 20 000 ₽ через 30–90 дней

Что находится в реальном аудите

Три реальных findings из отчёта выше — с confidence, impact и готовыми SQL-командами. Каждое исправление проверено сравнением «до / после».

CRITICALConfidence: 99%

Нет Primary Key

public.pgbench_accounts · 1 000 000 строк

Impact

Без PK невозможна логическая репликация, медленные UPDATE/DELETE идут через full scan, нет защиты от дубликатов. На миллионе строк каждое обновление сканирует всю таблицу.

Recommendation
ALTER TABLE "public"."pgbench_accounts"
  ADD COLUMN IF NOT EXISTS id BIGSERIAL;
CREATE UNIQUE INDEX CONCURRENTLY
  "pgbench_accounts_pkey"
  ON "public"."pgbench_accounts"(id);
ALTER TABLE "public"."pgbench_accounts"
  ADD PRIMARY KEY USING INDEX
  "pgbench_accounts_pkey";
Исправлено в отчёте «ПОСЛЕ» · 0 новых проблем
CRITICALConfidence: 99%

Autovacuum глобально отключён

Database-level · current_setting('autovacuum') = 'off'

Impact

База не очищает dead tuples автоматически. Со временем таблицы раздуваются, чтение замедляется, индексы деградируют. В production это приводит к каскадной деградации производительности.

Recommendation
ALTER SYSTEM SET autovacuum = 'on';
SELECT pg_reload_conf();
Исправлено в отчёте «ПОСЛЕ» · мгновенно
HIGHConfidence: 95%

Мёртвые кортежи 51.7%

public.pgbench_accounts · 516 957 dead / 1 000 000 live

Impact

Каждое чтение таблицы обрабатывает мусор. Cache hit ratio деградирует, планы запросов искажаются. На больших таблицах это критично — до 2x замедление всех SELECT.

Recommendation
VACUUM ANALYZE "public"."pgbench_accounts";
-- Или дождаться autovacuum, если включён.
Исправлено в отчёте «ПОСЛЕ»

Что проверяется

24+ автоматических проверок по шести категориям. Каждая находка содержит severity, evidence, confidence, impact, recommendation и готовый SQL.

🗄

Индексы

Отсутствующие, неиспользуемые, дублирующиеся и раздутые индексы. Проверка внешних и первичных ключей.

⚡

Скорость и память

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

📊

Состояние данных

Мёртвые строки, раздутие таблиц и индексов, актуальность статистики, нагрузка на autovacuum.

🔄

Транзакции и соединения

Долгие транзакции, зависшие сессии, избыточные idle-соединения, блокировки.

⚙

Настройки сервера

work_mem, логирование медленных запросов, таймауты, pg_stat_statements, autovacuum.

⚠

Риски и лимиты

Исчерпание sequence, устаревшая версия PostgreSQL, ошибки контрольных сумм, кандидаты на партиционирование.

Что собирает Collector

PG Audit Collector работает локально на сервере PostgreSQL, подключается read-only и собирает технические метаданные: конфигурацию, схему, статистику таблиц и индексов, активные расширения, WAL. Сбор snapshot занимает секунды. Анализ выполняется отдельно — по готовому JSON.

  • Read-only доступ. Collector не выполняет модифицирующих запросов, не пишет в системные таблицы.
  • Снимок за секунды. Один момент времени, без постоянного мониторинга — нет нагрузки на production. Анализ выполняется отдельно по готовому JSON.
  • Нет данных пользователей. Не читает содержимое ваших таблиц — только технические метаданные.
  • Поддержка PostgreSQL 12+. Включая последние release 16 и 17.
Скачать PG Audit Collector

Содержимое audit_data.json

{
  "collector": { "name": "pg_audit_collector",
                  "version": "1.0.4" },
  "server":    { "version": "PostgreSQL 16.0",
                  "uptime_seconds": 2100,
                  "config": { "autovacuum": "off",
                              "work_mem": "4MB", ... } },
  "database":  { "name": "pg_audit_test",
                  "size_pretty": "1536 MB" },
  "tables":    [ { "name": "pgbench_accounts",
                   "rows": 1000000,
                   "dead_ratio": 0.3412,
                   "has_primary_key": false },
                 { "name": "pgbench_history",
                   "rows": 950000,
                   "dead_ratio": 1.0,
                   "has_primary_key": false }, ... ],
  "stats":     { "cache_hit_ratio": 0.9819,
                  "temp_files": 14, ... }
}

Почему это безопаснее традиционного формата аудита

Сравнение двух моделей оказания услуги. Не нападка на конкурентов — у каждой модели свои компромиссы.

Не нужен remote admin access

Вы не открываете порт PostgreSQL в интернет. Collector запускается локально.

Не нужно давать пароль

PG_Collector использует существующий локальный доступ через Unix-socket.

Collector работает локально

На вашем сервере. Вы сами контролируете окружение и тайминги.

Snapshot, не live monitoring

Сбор snapshot занимает секунды. Никакого постоянного наблюдения за запросами.

Express Audit в браузере

JSON не отправляется на сервер. Весь анализ происходит локально.

Оптимизация без прямого доступа

Эксперт получает диагностический JSON, не доступ к вашей PostgreSQL.

ПараметрТрадиционный формат аудитаPG Audit
Сбор данныхРучной сбор нескольких артефактов клиентом: статистика, SQL, структура БД, архивированиеОдин автоматизированный snapshot через Collector
Доступ к даннымФайлы передаются специалисту для анализаCollector не передаёт данные автоматически; клиент сам контролирует передачу JSON
СрокиДо 1 недели на анализДо 24 часов
РезультатТекстовые рекомендации + SQL-скриптыHTML-отчёт с evidence + готовый remediation.sql + сравнение «до / после»
Контроль результатаПовторный анализ через месяц-два вручнуюRepeat Check по новому snapshot — автоматически
СтоимостьЗависит от объёма работ, обсуждается индивидуально30 000 ₽ (фиксированная цена)

Сравнение основано на публично описанном формате услуги; фактический процесс и стоимость других поставщиков могут отличаться. Профессиональный DBA может провести аудит через VPN, bastion, SSH или read-only роль — здесь сравниваются именно модели оказания услуги «под ключ».

Что вы получаете за 30 000 ₽

Конкретные файлы, не «анализ в свободной форме». Можно открыть, скачать, проверить до покупки — на реальном demo выше.

audit-report-before.html

Полный HTML-отчёт: 24+ проверок, severity, evidence, impact, confidence, recommendation. Executive summary + Quick Wins + план исправлений.

≈ 39 KB · открывается в браузере

remediation.sql

Готовый SQL под вашу версию PostgreSQL. Размечен по зонам: MUST_FIX / SHOULD_FIX / OBSERVE. Каждая команда с риском и confidence.

≈ 5 KB · применяете сами

audit-report-after.html

После применения SQL — новый snapshot и отчёт. Подтверждение, что рекомендации сработали на вашей инфраструктуре.

включено в Repeat Check

comparison-report.html

Diff «до / после»: сколько проблем исправлено, сколько новых появилось. Идеально для отчёта руководству.

включено в Repeat Check

SQL не выполняется автоматически. Вы полностью контролируете применение.

remediation.sql — это набор рекомендаций, не авто-исправление. Каждая команда размечена по уровню риска (HIGH / MEDIUM / LOW). Безопасные изменения (создание индексов CONCURRENTLY, ALTER SYSTEM с reload) обычно не требуют downtime, но применение в production должно выполняться после проверки конкретной команды и условий вашей инфраструктуры. Рискованные (изменение структуры таблиц) — сначала на staging, под нагрузкой, с резервной копией. Решение, что и когда применять, остаётся за вами.

LOW RISK — можно сразуMEDIUM RISK — staging рекомендованHIGH RISK — только staging + бэкап

Стоимость

Прозрачно, без скрытых платежей. Express Audit — навсегда бесплатно.

Бесплатный чек

Мгновенная оценка в браузере

0 ₽
  • Загрузите audit_data.json в браузер
  • Мгновенный результат — что обнаружено
  • Количество проблем по уровням критичности
  • Данные не покидают браузер
  • Без регистрации
Запустить бесплатный чек
Рекомендуем

PostgreSQL Optimization

Стандартизированный анализ + готовый remediation SQL

30 000 ₽
  • Полный диагностический анализ PostgreSQL
  • Приоритетный план исправлений (Quick Wins / Strategic / Long-term)
  • Готовый remediation.sql под вашу версию PG
  • Оценка трудозатрат и рисков по каждому пункту
  • Сравнение «до / после» через Repeat Check
  • HTML-отчёт с evidence, impact, confidence
  • SQL-команды размечены по зонам безопасности (зелёная / жёлтая / оранжевая)
  • Поддержка PostgreSQL 12, 13, 14, 15, 16, 17
Получить план оптимизации

Repeat Check

Финальный шаг цикла: доказательство, что рекомендации сработали

20 000 ₽
  • Новый snapshot через 30–90 дней после применения SQL
  • Сравнение «до / после» — что исправлено, что появилось
  • Отдельный comparison-report.html для руководства
  • Новый remediation.sql для оставшихся проблем
  • На тестовом стенде: 5 из 5 Critical/High исправлено, 0 новых
Заказать Repeat Check

90 дней — не маркетинговый срок. Это минимальное время, за которое PostgreSQL накапливает достаточно статистики (pg_stat_user_tables, pg_stat_user_indexes) для корректного сравнения. Повтор раньше — сравнение будет некорректным.

PG Audit Cases в Telegram

Кейсы аудита, разборы проблем PostgreSQL, обновления продукта. Подписывайтесь на канал — там же можно задать вопросы и обсудить вашу инфраструктуру.

Открыть Telegram

Ключевые вопросы

6 самых частых вопросов. Полный список (23 вопроса) — на странице /faq.

Q.Можно ли запускать Collector на production?

Да. Collector подключается read-only через системные представления. Не выполняет модифицирующих запросов, не блокирует транзакции. Внутренние тесты показывают сбор snapshot за секунды на базах до 100 GB.

Q.Нужен ли superuser?

Нет. Достаточно встроенной роли pg_read_all_stats или SELECT прав на системные catalog'и. Часть проверок (pg_hba.conf) будет недоступна — помечаются N/A.

Q.Читает ли Collector данные таблиц?

Нет. Только метаданные: pg_settings, pg_stat_user_tables, pg_class. Содержимое таблиц, тексты SQL, пароли — не читаются.

Q.SQL выполняется автоматически?

Нет. remediation.sql — это набор рекомендаций. Каждая команда снабжена риском (LOW/MEDIUM/HIGH). Клиент сам решает что и когда применять.

Q.Что если рекомендация неприменима?

Это нормально. Часть рекомендаций основана на эвристиках. Просто не выполняйте эту команду. По сомнительным finding можно задать вопрос в Telegram.

Q.Что если после SQL что-то сломалось?

Создайте резервную копию перед применением. Каждая команда снабжена обратной операцией. При невозможности отката — восстанавливайтесь из бэкапа. По всем случаям — пишите в Telegram с темой [Issue].

Все 23 вопроса

Бесплатные инструменты

Не требуют регистрации. Полезны сами по себе.

Калькулятор стоимости простоя

Рассчитайте стоимость часа и минуты простоя базы данных, потенциальную месячную потерю и допустимый простой по SLA.

Открыть калькулятор
Генератор конфигурации PostgreSQL

Контекстно-зависимая конфигурация под ваши RAM, CPU, storage и workload. С пояснениями и диапазонами.

Открыть генератор

Запустите Collector — узнайте, что нашёл аудит у вас

Бесплатно. Без регистрации. Данные остаются в вашем браузере.

Запустить бесплатный чекПолучить план оптимизации — 30 000 ₽