Холодный старт слишком медленный

Если cold start кажется слишком долгим, сначала важно понять, что именно тормозит:

• база честно просыпается после stopped;
• платформе не хватает ресурсов для быстрого запуска writer;
• Compute не проходит soft bootstrap / readiness;
• Pageserver или Safekeeper под нагрузкой;
• приложение обрывает попытку слишком ранним таймаутом;
• в этот момент идёт autoscale handoff или cooldown.

Что важно помнить

В SPG99 cold start — нормальная часть serverless‑модели. После обновления платформы он идёт через:

• soft basebackup;
• тонкий startup‑образ;
• минимальный локальный набор данных на pod’е;
• ленивое дочитывание пользовательских relation pages.

Это заметно быстрее тяжёлого локального restore, но не делает первый connect мгновенным во всех случаях.

Что проверить

1. Была ли база действительно в stopped?
2. Переходит ли она из booting в ready, или зависает?
3. Какой сейчас scale_state?
4. Не слишком ли мал connect_timeout у клиента?
5. Есть ли ошибки в Logs и признаки проблем в Metrics?
6. Нет ли pinned/session трафика, из‑за которого платформа сейчас не может быстро завершить handoff?

Типовые причины

• storage‑контур под нагрузкой;
• база давно не запускалась;
• одновременно стартуют несколько БД;
• Pageserver догоняет нужный WAL диапазон;
• первый remote read‑through на горячие страницы занимает заметное время;
• платформа сейчас находится в PREPARING, DRAINING или COOLDOWN.

Что помогает

• разумный retry на connect;
• connect_timeout не менее 5–10s;
• проверка state и scale_state через Console / API;
• анализ логов и метрик вместо догадок;
• прогревающий connect перед критичным окном нагрузки.

Практический вывод

Если cold start стабильно выходит за ожидаемые рамки, проблема обычно находится не в самом факте stopped, а в том, как платформа проходит путь:

• storage -> soft basebackup -> ready,
• или profile handoff -> freeze/drain -> ready.