Основы тюнинга производительности

SPG99 уже делает важную часть тюнинга автоматически: Compute сам рассчитывает базовую конфигурацию PostgreSQL по профилю, типу нагрузки и доступным ресурсам. Поэтому главная задача пользователя — правильно работать с соединениями, запросами и наблюдаемостью, а не вручную выставлять десятки low‑level параметров.

1. Управляйте количеством соединений

Даже при достаточно высоком max_connections слишком много одновременных соединений вредят:

• растёт overhead внутри PostgreSQL;
• ухудшается latency;
• снижается эффективность Gateway pooling;
• сложнее проходит autoscale handoff.

Практика:

• для долгоживущих сервисов используйте pool соединений;
• для jobs и serverless‑нагрузки открывайте соединение по необходимости и закрывайте его после работы;
• не рассматривайте высокий max_connections как цель саму по себе.

2. Учитывайте soft cold start

В SPG99 sleeping‑база просыпается через soft basebackup и тонкий startup‑образ. Это быстрее, чем тяжёлый полный restore, но первая попытка всё равно может быть заметно медленнее warm‑path.

Поэтому:

• драйвер должен уметь retry на connect;
• критичные сервисы стоит прогревать обычным connect/check заранее;
• нельзя интерпретировать каждый первый медленный connect как “поломку платформы”.

3. Не ломайте autoscale session‑state’ом без необходимости

Новый writer autoscaler делает generation handoff. Для него хуже всего, когда приложение без необходимости создаёт много session‑heavy соединений.

Особенно мешают:

• SET на долгих сессиях;
• temp tables;
• LISTEN/UNLISTEN;
• named prepared statements, если их можно избежать;
• долгие idle‑, но pinned‑соединения.

Если workload реально stateless, Gateway и autoscaler работают заметно эффективнее.

4. Не пытайтесь вручную заменить managed‑конфиг

Платформа сама рассчитывает:

• shared_buffers;
• work_mem;
• maintenance_work_mem;
• effective_cache_size;
• max_connections;
• часть параметров параллелизма и внутренних настроек spg99.

Поэтому стандартная рекомендация такая:

• не тюньте эти параметры вручную глобально;
• не пытайтесь использовать запрещённые env‑override;
• если нужен локальный эксперимент под один запрос — применяйте SET LOCAL внутри транзакции и контролируйте эффект по метрикам.

5. Следите за долгими транзакциями

В любой PostgreSQL‑системе именно долгие транзакции часто создают реальные проблемы:

• удерживают xmin;
• мешают vacuum;
• раздувают таблицы и индексы;
• блокируют downscale/handoff безопасного writer autoscaler.

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

• не держите транзакции открытыми минутами без необходимости;
• используйте idle_in_transaction_session_timeout;
• следите за long tx в Monitoring.

6. Используйте pg_stat_statements

В SPG99 pg_stat_statements включён по умолчанию, поэтому для поиска bottleneck почти всегда начинайте с него.

Это позволяет:

• находить самые дорогие запросы;
• видеть часто повторяющиеся шаблоны;
• сравнивать среднее и суммарное время.

Нужно помнить: Compute — stateless‑исполнитель, поэтому после рестарта статистика может сброситься. Это нормально.

7. Когда пора переходить на следующий размер

Подумайте о переходе на следующий size, если регулярно видите:

• CPU у верхней границы;
• нехватку памяти под рабочий набор;
• постоянные pool checkout timeouts;
• невозможность уложиться в SLO даже после оптимизации SQL.

В SPG99 обычно надёжнее перейти на следующий размерный класс, чем пытаться “дожать” текущий ручными override‑параметрами.

8. Используйте наблюдаемость как основной инструмент тюнинга

Для регулярной диагностики смотрите:

• метрики CPU, памяти, соединений и cold start;
• активные запросы и блокировки;
• current_profile, target_profile, scale_state;
• Gateway pooling и признаки pinned traffic;
• логи Compute/PostgreSQL.

Лучший тюнинг — это не настройка “наугад”, а изменение по фактическим данным из Monitoring.