CPU

Описание

CPU - процессорное время.

Если CPU занят, сервису не хватает времени выполнять код.

Не путать:

  • CPU 100% - процессор реально занят.

  • Load Average высокий - процессы ждут CPU или I/O.

Связанные темы:

RAM

Disk

USE

CPU в PostgreSQL

Куда тратится CPU

  • выполнение кода приложения,

  • сериализация JSON/XML,

  • шифрование TLS,

  • сжатие/распаковка,

  • сортировки,

  • агрегации,

  • join в БД,

  • парсинг SQL и построение плана,

  • фоновые задачи.

В БД

CPU чаще всего тратится на:

  • фильтрацию строк,

  • JOIN,

  • ORDER BY,

  • GROUP BY,

  • DISTINCT,

  • вычисления в SELECT,

  • проверку ограничений и индексов при INSERT/UPDATE.

Связанные страницы:

DML SELECT

JOIN

Explain

Планировщик запросов и EXPLAIN

Join-алгоритмы и сортировки

Индексы в PostgreSQL

Сколько CPU нужно примерно

Это порядок, не точная формула.

  • 0.1-0.5 vCPU - маленький сервис, cron, nginx, редкие запросы.

  • 0.5-1 vCPU - небольшой API без тяжёлых вычислений.

  • 1-2 vCPU - обычный backend сервис, средняя нагрузка.

  • 2-4 vCPU - небольшой PostgreSQL, dev/test, маленький prod.

  • 4-8 vCPU - PostgreSQL с живым prod, отчётами, join, сортировками.

  • 8+ vCPU - много параллельных запросов, аналитика, highload.

Важно:

  • БД может упереться не в CPU, а в Disk.

  • 1 тяжёлый запрос может съесть CPU сильнее, чем 100 простых.

  • много соединений к БД не равно много полезной работы.

Примеры SQL

Дёшево, если есть индекс по id:

SELECT *
FROM users
WHERE id = 10;

Дороже, если таблица большая и индекса нет:

SELECT *
FROM users
WHERE email = 'test@mail.ru';

JOIN может быть дорогим:

SELECT o.id, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at >= '2026-01-01';

GROUP BY + ORDER BY часто едят CPU и память:

SELECT user_id, count(*)
FROM orders
GROUP BY user_id
ORDER BY count(*) DESC;

Смотреть план:

EXPLAIN ANALYZE
SELECT o.id, u.email
FROM orders o
JOIN users u ON u.id = o.user_id;

Как оптимизировать

  • смотреть Explain,

  • добавлять индексы под частые фильтры и join,

  • не тащить SELECT *,

  • ограничивать выборку через WHERE, LIMIT,

  • не делать тяжёлые отчёты в пик нагрузки,

  • выносить долгие задачи в очередь,

  • кэшировать частые чтения,

  • батчить массовые операции,

  • проверять, не ждёт ли запрос диск или lock.

Последнее обновление