Моніторинг продуктивності БД: pg_stat_statements та slow query log

Уявіть: ваш інтернет-магазин навантажує базу, кожні 5 хвилин сторінки завантажуються по 10 секунд, а в пік продажів сайт лягає. Ви перевіряєте сервер — CPU вільний, пам'яті запас, а запити все одно повільні. Без моніторингу продуктивності БД ви шукаєте проблему наосліп. Ми налаштовуємо pg_stat_statements та slow query log, підключаємо Prometheus із Grafana — і ви бачите точні метрики: cache hit rate, лаг реплікації, найважчі запити. За 2 дні ви отримуєте дашборди, які в реальному часі показують, які запити гальмують систему. Це не разова перевірка — це постійний контроль.

Ми вже стикалися з ситуацією, коли один повільний JOIN через неправильний індекс з'їдав 40% часу бази. Після налаштування моніторингу клієнт знайшов і виправив проблему за годину. Економія на операційних витратах сягає 30% за рахунок зниження простоїв. Оцінимо ваш проект безкоштовно — напишіть нам.

Як pg_stat_statements допомагає виявити повільні запити?

Розширення pg_stat_statements накопичує статистику по кожному унікальному запиту: час виконання, кількість викликів, стандартне відхилення. Конфігурація мінімальна:

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.max = 10000
pg_stat_statements.track = all
pg_stat_statements.track_utility = off

Після перезапуску створіть розширення та виконайте запит для пошуку проблем:

-- Топ за сумарним часом
SELECT left(query, 120) AS query, calls,
       round(total_exec_time::numeric / 1000, 1) AS total_sec,
       round(mean_exec_time::numeric, 1) AS avg_ms,
       round(stddev_exec_time::numeric, 1) AS stddev_ms,
       round(rows::numeric / nullif(calls, 0), 0) AS rows_per_call
FROM pg_stat_statements
WHERE dbid = (SELECT oid FROM pg_database WHERE datname = current_database())
  AND calls > 10
ORDER BY total_exec_time DESC
LIMIT 20;

-- Запити з великим розкидом часу
SELECT left(query, 120) AS query, calls,
       round(mean_exec_time::numeric, 1) AS avg_ms,
       round(stddev_exec_time::numeric, 1) AS stddev_ms,
       round(stddev_exec_time / nullif(mean_exec_time, 0) * 100, 1) AS cv_pct
FROM pg_stat_statements
WHERE calls > 100
ORDER BY cv_pct DESC
LIMIT 10;

На одному проекті ми виявили запит, який виконувався в середньому 2,3 секунди і займав 15% від загального часу БД. Після додавання індексу час впав до 15 мс — прискорення в 153 рази. pg_stat_statements documentation підтверджує, що це найшвидший спосіб отримати агреговану картину. У порівнянні з slow query log:

Разом вони в 3 рази швидше допомагають локалізувати вузьке місце, ніж ручний перегляд логів.

Чому slow query log важливий для MySQL?

У MySQL вмикаємо slow query log з порогом 1 секунда та логуванням запитів без індексів:

slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
min_examined_row_limit = 1000
log_slow_rate_limit = 100

Типовий випадок: запит без індексу сканував 500 000 рядків, виконуючись 4,2 секунди. Після аналізу ми додали складений індекс, і час скоротився до 0,03 секунди — зниження на 99,3%. Аналізуємо через Percona Toolkit:

pt-query-digest --since="1h ago" --limit 20 --output report /var/log/mysql/slow.log

Це дає count, avg/max time та rows examined для кожного унікального запиту.

Метричний моніторинг: Prometheus + Grafana

Для PostgreSQL використовуємо postgres_exporter, для MySQL — mysqld_exporter. Конфігурація експортерів стандартна, налаштовується за годину. Ключові метрики та алерти:

Приклад правил алертингу:

groups:
  - name: postgresql
    rules:
      - alert: PostgreSQLSlowQueries
        expr: rate(pg_stat_statements_total_exec_time_seconds_total[5m]) > 10
        for: 2m
      - alert: PostgreSQLHighConnections
        expr: pg_stat_activity_count > pg_settings_max_connections * 0.8

Ви можете імпортувати готові дашборди Grafana (ID 9628 для PostgreSQL, 7362 для MySQL).

Що входить у роботу з налаштування моніторингу БД?

Ми надаємо повний комплект документації: опис конфігурації доступів, інструкції з розгортання, керівництво з дій при спрацьовуванні алертів. Після впровадження ви отримуєте:

• Налаштовані експортери для PostgreSQL та MySQL.
• Дашборди Grafana з ключовими метриками (cache hit rate, лаг реплікації, топ запитів).
• Кастомні алерти з відправкою в Telegram або Slack.
• Навчання команди: як інтерпретувати метрики та реагувати на алерти.
• Щоденні звіти pgBadger по повільних запитах.

Це дозволяє вашій команді самостійно підтримувати продуктивність БД без зовнішньої допомоги. Вартість впровадження окупається за 2 місяці за рахунок скорочення простоїв. Отримайте консультацію — ми оцінимо ваш проект за 1 годину.

Які етапи включає налаштування моніторингу БД?

1. Аналітика: збір поточних метрик, виявлення вузьких місць за логами та статистикою.
2. Налаштування pg_stat_statements та slow_query_log з оптимальними параметрами.
3. Деплой Prometheus експортерів (postgres_exporter, mysqld_exporter).
4. Створення кастомних дашбордів Grafana з ключовими метриками cache hit rate, лагу реплікації, топ запитів.
5. Налаштування алертів в Alertmanager з відправкою в Telegram/Slack.
6. Інтеграція pgBadger для щоденних звітів та навчання команди.
7. Документація з конфігурації та дій при спрацьовуванні алертів.

Які типові помилки допускають при налаштуванні моніторингу БД?

• Не вмикають pg_stat_statements.track_utility = off — засмічують статистику службовими запитами.
• Забувають налаштувати log_line_prefix для MySQL — втрачають контекст у slow log.
• Використовують один дашборд для всіх баз — ігнорують специфіку реплікації та шардингу.
• Не встановлюють поріг alertmanager на burst — отримують спам при короткочасних сплесках.

Ми виправляємо ці помилки на етапі впровадження. Наші інженери мають 5+ років досвіду в адмініструванні PostgreSQL та MySQL, сертифіковані по Prometheus. Більше 10 проектів з оптимізації продуктивності БД гарантують результат. Після впровадження моніторингу клієнти економлять до 40% часу на діагностику та скорочують простої вдвічі. Замовте налаштування моніторингу БД — і ми виявимо вузькі місця за 2 дні.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.