Перейти к содержимому

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

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

Метрика На что влияет
invocations Контекст нагрузки; отдельного начисления за вызов нет
cpu_seconds Вклад CPU в единую метрику Compute CU
memory_gb_seconds Вклад памяти в единую метрику Compute CU
compute_seconds Вклад времени жизни процесса, включая потоковые ответы и WebSocket, в единую метрику Compute CU

Все ресурсные показатели ONREZA Compute сводятся в один тарифицируемый line item process_compute_cu_seconds; они не суммируются как независимые услуги.

Метрика На что влияет
static_egress_gb Стоимость доставки файлов
static_storage_gb_month Стоимость хранения артефактов
static_image_transforms Стоимость трансформации изображений
static_origin_fetch_gb Стоимость обращений к origin
Метрика На что влияет
compute_cu_seconds Стоимость CU-weighted вычислительного времени БД; в счёте нормализуется блоками по 1 CU-часу
storage_gb_month Стоимость хранения данных по времени (включает written_data)
transfer_gb Стоимость сетевого трафика к БД
database_months Время активности баз данных; на Hobby и Pro ставка нулевая, в Enterprise определяется договором
branch_months Время активности веток БД для статистики и лимитов; отдельного начисления нет
Метрика На что влияет
build_minutes Стоимость сборок
kv_storage_mb Ограничение объёма KV
  1. Смотрите дневной тренд по каждой метрике
  2. Выделяйте дни с резким ростом (spikes)
  3. Сверяйте всплески с релизами и изменениями трафика
  4. Проверяйте, какая именно метрика и какого слоя дала основной вклад в gross/extra usage
  1. Откройте Usage за текущий период.
  2. Определите, какие слои использует ваше приложение.
  3. Найдите метрику с наибольшим отклонением от базового тренда.
  4. Сопоставьте отклонение с релизом, фичей или нагрузочным событием.
  5. Примените оптимизацию и сравните результат на 7-дневном окне.
  • Рост cpu_seconds при стабильных invocations — усложнение обработки запроса
  • Рост memory_gb_seconds — большие объекты и долгие операции
  • Рост compute_seconds при стабильном трафике — долгие ответы, WebSocket-соединения или неэффективное удержание экземпляров
  • Рост kv_storage_mb — крупные значения, много ключей без TTL или отсутствие cleanup
  • Рост static_egress_gb — увеличение размера файлов или трафика
  • Рост static_origin_fetch_gb — низкий cache hit rate
  • Рост static_image_transforms — много вариантов изображений
  • Рост compute_cu_seconds — долгоживущие соединения, частые запросы, большой CU size, отсутствие connection pooling
  • Рост storage_gb_month — накопление данных, раздутый WAL, отсутствие очистки или долго хранимые данные
  • Рост transfer_gb — тяжёлые выборки, отсутствие пагинации
Слой Сценарий Что делать
ONREZA Compute Много вызовов кэш, дедупликация, rate limiting
ONREZA Compute Высокий CPU профилирование, precompute
ONREZA Compute Рост памяти потоковая обработка, уменьшение данных
KV-хранилище Рост storage TTL для временных ключей, удаление старых данных, уменьшение payload
KV-хранилище Много reads/writes батчинг, локальный cache, уменьшение размера value/metadata
Статические сайты и CDN Высокий egress сжатие, оптимизация бандлов
Статические сайты и CDN Cache miss увеличение TTL, stale-while-revalidate
PostgreSQL Высокие CU-часы connection pooling, авто-suspend, меньший CU size
PostgreSQL Рост storage VACUUM, архивирование, удаление старых данных
PostgreSQL Высокий transfer пагинация, выборка только нужных колонок

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