Взято с основного технического канала Postgres DBA ( возможны правки и дополнения в исходной статье ).

Начало

Эскизный проект

ℹ️Текущие возможности

✅Снимки pg_stat_activity , pg_locks , PostgreSQL RAM utilization.

✅Сбор статистических данных для оценки производительности на уровне СУБД.

✅Сбор статистических данных для оценки производительности на уровне SQL выражения.

✅История инцидентов снижения операционной скорости СУБД.

✅Связь между инцидентами и SQL выражениями.

✅Оперативная и сводная отчётность по инцидентам и нагрузочному тестированию.

✅Метрики оценки и мониторинга производительности СУБД.

✅Методология анализа инцидентов.

Вопрос: Какой мониторинг выгоднее использовать для оптимизации производительности СУБД PostgreSQL - реактивный или проактивный ?

Ответ DeepSeek

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

### Почему проактивный мониторинг выгоднее:
1. **Предупреждение проблем**:
- Отслеживание метрик (CPU, память, I/O, индексы, блокировки) помогает выявить узкие места до их критического влияния.
- Пример: мониторинг роста таблиц или замедления запросов через `pg_stat_statements` позволяет заранее оптимизировать индексы или переписать запросы.

2. **Снижение простоев**:
- Анализ трендов (например, заполнение диска или увеличение времени ответа) позволяет планировать масштабирование и обновления.

3. **Экономия ресурсов**:
- Проактивное устранение проблем дешевле, чем аварийное восстановление после сбоев.

4. **Инструменты**:
- Prometheus + Grafana для сбора метрик.
- Настройка алертов на аномалии (например, через Alertmanager).
- Использование расширений PostgreSQL: `pg_stat_activity`, `pg_stat_bgwriter`, `pg_stat_statements`.

### Когда полезен реактивный мониторинг:
- Для анализа уже возникших инцидентов (например, внезапные блокировки или деградация запросов).
- Использование логов и инструментов вроде `pgBadger` для постфактум-анализа.
- Оптимизация запросов, которые не были выявлены проактивно.

### Итог:
- **Проактивный мониторинг** — основа для долгосрочной стабильности и оптимизации.
- **Реактивный** — дополнение для работы с непредвиденными сценариями.
- Для максимальной эффективности объедините оба подхода, но фокусируйтесь на проактивных методах.

В начале 2024 года, в условиях активного импортозамещения и опасений возможных принудительных мер со стороны властей по переходу на отечественное ПО, мы начали искать альтернативные решения. Основываясь на опыте использования 1С, которое активно применяется в России, и после изучения материалов Гилева, мы решили рассмотреть PostgresPro Ent.

Проведя базовые тесты, нас устроила его функциональность, встроенная кластеризация BiHa PostgresPro Ent и административная панель PPEM. Все выглядело красиво и удобно. В итоге было принято решение закупить лицензии на PostgresPro Ent для двух серверов и развернуть на них часть баз 1С.

Развертывание прошло быстро и без значительных затруднений. Мы создали несколько инстансов для удобства восстановления, так как в отличие от MSSQL, в Postgres нельзя работать с резервными копиями отдельных баз данных без риска потери данных, а только с инстансом целиком.

В процессе эксплуатации выявились некоторые неприятные особенности. В частности, очень долгое резервное копирование с использованием pg_probackup. База 1С на MS SQL, объемом около 100 ГБ, копируется на сервер резервного копирования за 5-10 минут, в то время как аналогичная база на PostgresPro Enterprise требует более 2 часов. Многие могут предложить использовать более мощное оборудование или смотреть в сторону инкрементальных бэкапов (в плане обслуживания MSSQL мы используем как полные таки и инкрементальные). Но проблема заключается в самой логике работы pg_probackup, которая не позволяет сразу архивировать все файлы в один архив и далее работать уже с ними, а фактически учитывая структуру базы 1С там не одна тысяча мелких файлов которые очень "замечательно" копируются по сети, даже 10GBps не изменяет ситуацию. Также возникло множество мелких вопросов, требующих дополнительных компетенций, но пути решения были найдены, хотя и не всегда оптимальные. Вывод: PostgresPro требуется значительного много времени что бы догнать MS SQL в удобстве использования и обслуживания.

Однако главная особенность PostgresPro Enterprise заключается в следующем: при покупке бессрочной лицензии PostgresPro Enterprise, после окончания базовой подписки на техническую поддержку, вы не можете использовать ПО как вам хочется. Вы становитесь привязанными к тому оборудованию, на которое было установлено ПО (вспомним OEM лицензии от MicroSoft), и ваша бессрочная лицензия фактически превращается в лицензию по подписке. Этот факт выяснился через год после покупки, когда мы решили заменить серверы на более новые. Доступ к репозиторию уже был закрыт, так как закончился срок базовой техподдержки. Обращения в техническую поддержку не дали результатов: ответ сводился к предложению купить подписку на техническую поддержку или отказаться от использования ПО.

Таким образом, могу посоветовать: тщательно взвесить все за и против перед переходом на отечественное ПО, чтобы избежать подобных проблем.

p.s. Если у администрации ресурса возникнут сомнения в правдивости этого поста, могу предоставить номера обращений и даже предоставить скрины ответов PostgresPro Enterprise.