> Как решать проблему нагрузки на CPU в сервисе (JavaScript)

Короткий ответ

Проблема нагрузки на CPU в Node.js решается через оптимизацию event loop, вынос тяжёлых вычислений в worker threads или child processes, использование кластеризации, профилирование с помощью clinic.js или 0x, и внедрение кэширования. Ключевое - не блокировать event loop синхронными операциями, избегать O(n²) алгоритмов в горячих путях и применять streaming для больших данных.

Подробное объяснение

Node.js работает в одном потоке с event loop, поэтому любая синхронная CPU-интенсивная задача блокирует обработку всех запросов. Основные причины высокой нагрузки: неэффективные алгоритмы (например, рекурсия без мемоизации), парсинг больших JSON/XML без streaming, частые вычисления в циклах, утечки через setInterval без очистки, и избыточная десериализация.

Подходы к решению:

• Профилирование: используйте clinic doctor или 0x для выявления узких мест, смотрите на flamegraph и async hooks.
• Разделение задач: выносите тяжёлые вычисления в worker_threads (для CPU-bound) или child_process (для изоляции). Worker threads разделяют память с основным потоком через SharedArrayBuffer, что снижает накладные расходы.
• Кластеризация: запускайте несколько процессов через cluster модуль, распределяя запросы round-robin. Это масштабирует использование многоядерных CPU.
• Оптимизация кода: избегайте JSON.parse на больших строках - используйте streaming парсеры (например, stream-json). Заменяйте for...of на обычный for в горячих циклах. Применяйте мемоизацию для чистых функций.
• Кэширование: используйте in-memory кэш (Map, Redis) для результатов дорогих вычислений, устанавливайте TTL.
• Асинхронность: разбивайте длинные синхронные операции на микротаски через setImmediate или queueMicrotask, чтобы дать event loop обработать другие запросы.

На практике

Начните с профилирования: запустите clinic doctor -- node app.js, затем воспроизведите нагрузку. Если flamegraph показывает длинные синхронные участки - это блокировка event loop. Для типичного backend-сервиса:

1. Определите hot path: например, обработка загрузки CSV с 100k строк. Если парсинг синхронный - вынесите в worker thread.
2. Для API с частыми вычислениями (хеширование, шифрование) используйте worker_threads с пулом из 2-4 воркеров на ядро.
3. Если сервис обрабатывает много запросов - добавьте кластеризацию: cluster.fork() по числу CPU.
4. Для кэширования результатов сложных запросов к БД используйте Redis с TTL 5-10 секунд, чтобы снизить нагрузку на CPU от повторных вычислений.
5. Мониторьте CPU через process.cpuUsage() и устанавливайте алерты при превышении 80%.

Пример кода

JAVASCRIPT
// worker_threads для CPU-bound задачи
const { Worker } = require('worker_threads');

function runHeavyTask(data) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./heavy-task.js', { workerData: data });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`));
    });
  });
}

// heavy-task.js
const { parentPort, workerData } = require('worker_threads');
const result = expensiveCalculation(workerData);
parentPort.postMessage(result);

Как отвечать на собеседовании

Начните с диагностики: спросите, как измерялась нагрузка - через top, clinic или APM. Затем перечислите причины: блокировка event loop, неэффективные алгоритмы, отсутствие кэширования. Предложите конкретные решения: worker threads для вычислений, кластеризация для масштабирования, streaming для больших данных. Приведите пример из практики: "В проекте с парсингом логов мы вынесли разбор в worker thread и снизили latency с 2s до 50ms". Упомяните trade-off: worker threads увеличивают потребление памяти, кластеризация - сложность деплоя.

Что проверяет интервьюер

• Понимание event loop и его блокировки синхронными операциями.
• Знание инструментов профилирования (clinic, 0x, perf).
• Умение выбирать между worker threads, child processes и кластеризацией.
• Практический опыт оптимизации CPU-bound задач в Node.js.
• Понимание trade-off: память vs CPU, сложность кода vs производительность.

Типичные ошибки

• Предложение использовать только кластеризацию без анализа причин - она не решит блокировку event loop внутри одного процесса.
• Игнорирование профилирования: "я просто добавлю worker threads" без понимания, что именно тормозит.
• Использование child_process для лёгких задач - накладные расходы на создание процесса выше, чем выгода.
• Забывают про кэширование: повторные вычисления одинаковых данных убивают CPU.
• Не учитывают, что worker threads не работают с DOM или некоторыми native модулями (например, bcrypt требует отдельной настройки).