Использование ресурсов

Страница Usage нужна для ежедневного контроля: где растёт нагрузка и почему меняется счёт.

Метрики Compute

Метрика	На что влияет
invocations	Частота выполнения Runtime
cpu_seconds	Стоимость вычислений
memory_gb_seconds	Стоимость использования памяти
residency_seconds	Стоимость удержания экземпляров
streaming_seconds	Стоимость длительных стримов
websocket_seconds	Стоимость WebSocket-соединений

Метрики Isolate

Метрика	На что влияет
invocations	Частота edge-выполнений
cpu_seconds	Стоимость вычислений в isolate
memory_gb_seconds	Стоимость сконфигурированной памяти
subrequests	Стоимость внешних операций (KV, fetch)

Метрики Static

Метрика	На что влияет
egress_gb	Стоимость доставки файлов
storage_gb_month	Стоимость хранения артефактов
image_transforms	Стоимость трансформации изображений
origin_fetch_gb	Стоимость обращений к origin

Метрики Managed PostgreSQL

Метрика	На что влияет
cu_hours	Стоимость CU-weighted вычислительного времени БД
storage_gb	Стоимость хранения данных (включает written_data)
data_transfer_gb	Стоимость сетевого трафика к БД
extra_databases	Стоимость доп. баз данных сверх включённых
extra_branches	Стоимость доп. веток сверх включённых

Метрики Common

Метрика	На что влияет
build_minutes	Стоимость сборок
kv_storage_mb	Стоимость хранилища

Как читать графики

1. Смотрите дневной тренд по каждой метрике
2. Выделяйте дни с резким ростом (spikes)
3. Сверяйте всплески с релизами и изменениями трафика
4. Проверяйте, какая именно метрика и какого слоя дала основной вклад в overage

Рабочий процесс анализа

1. Откройте Usage за текущий период.
2. Определите, какие слои использует ваше приложение.
3. Найдите метрику с наибольшим отклонением от базового тренда.
4. Сопоставьте отклонение с релизом, фичей или нагрузочным событием.
5. Примените оптимизацию и сравните результат на 7-дневном окне.

На что обращать внимание

Compute

• Рост cpu_seconds при стабильных invocations — усложнение обработки запроса
• Рост memory_gb_seconds — большие объекты и долгие операции
• Рост residency_seconds при стабильном трафике — неэффективное удержание экземпляров

Isolate

• Рост subrequests — массовые обращения к KV/fetch в цикле
• Рост cpu_seconds при стабильных invocations — усложнение edge-логики
• Рост memory_gb_seconds — избыточный configured memory limit

Static

• Рост egress_gb — увеличение размера файлов или трафика
• Рост origin_fetch_gb — низкий cache hit rate
• Рост image_transforms — много вариантов изображений

Managed PostgreSQL

• Рост cu_hours — долгоживущие соединения, частые запросы, большой CU size, отсутствие connection pooling
• Рост storage_gb — накопление данных, раздутый WAL, отсутствие очистки
• Рост data_transfer_gb — тяжёлые выборки, отсутствие пагинации

Типовые действия для оптимизации

Слой	Сценарий	Что делать
Compute	Много вызовов	кэш, дедупликация, rate limiting
Compute	Высокий CPU	профилирование, precompute
Compute	Рост памяти	потоковая обработка, уменьшение данных
Isolate	Много subrequests	батчинг KV, кэширование fetch
Isolate	Высокий CPU	вынос тяжёлой логики в Compute
Static	Высокий egress	сжатие, оптимизация бандлов
Static	Cache miss	увеличение TTL, stale-while-revalidate
PostgreSQL	Высокие CU-часы	connection pooling, авто-suspend, меньший CU size
PostgreSQL	Рост storage	VACUUM, архивирование, удаление старых данных
PostgreSQL	Высокий transfer	пагинация, выборка только нужных колонок

Задержка данных

Usage-метрики могут появляться с небольшой задержкой из-за агрегации событий. Для финансовой сверки используйте значения закрытого расчётного периода.

Совет

Если нужна точная верификация суммы, используйте страницу формул: там описаны все переменные, единицы и правила округления.

См. также

• Pricing Appendix
• Слои и метрики
• Биллинг: базовый уровень
• Биллинг: практика
• Формулы и переменные
• Лимиты и квоты