Что блокирует цикл: CPU-работа и синхронные вызовы

Эндпоинт health-check, который не делает ничего, кроме возврата 200 OK, начинает отваливаться по таймауту. Его никто не трогает; его код — две строки. Настоящая причина в трёх роутах отсюда: репортинговый эндпоинт вызывает JSON.parse на теле в 40 МБ, и те ~800 мс, что этот парс работает, единственный поток цикла занят, и каждый другой запрос — включая тривиальный health-check — сидит замороженным в очереди. Никто не писал медленный health-check. Кто-то написал одну медленную синхронную строку, и кооперативная конкурентность разнесла боль на весь процесс.

Один медленный колбэк стопорит всех

Выигрыш прошлого урока и его цена — один и тот же факт: колбэки выполняются до конца без вытеснения. Пока всё уступает быстро — await на I/O, быстрый возврат — тысячи соединений плавно чередуются. Но в момент, когда один колбэк делает синхронную работу, занимающую реальное время, цикл не может продвинуться к фазе poll, не может выполнить ни один другой I/O-колбэк, не может запустить ни один таймер. Цена не «этот запрос медленный». Это head-of-line blocking для всего процесса: каждый конкурентный запрос платит полную длительность, потому что все они ждут за одним колбэком, захватившим поток.

Это определяющий режим отказа модели. В сервере поток-на-соединение один медленный запрос замедляет тот поток; здесь один медленный синхронный отрезок замедляет все.

Обычные виновники

Блокирующая работа бывает двух видов: синхронные API, делающие I/O на потоке цикла, и CPU-bound вычисления, которые просто слишком долго идут между уступками.

• Синхронные I/O API — fs.readFileSync, fs.writeFileSync, child_process.execSync. Они делают I/O на потоке цикла и могут застопорить его на сотни миллисекунд (синхронное чтение большого файла замерялось около 1200 мс). Асинхронные двойники (fs.promises.readFile) отдают работу и дают циклу продолжить.
• Большой JSON.parse / JSON.stringify — парсинг или сериализация многомегабайтного тела — это чистый CPU на потоке цикла; крупный парс замерялся около 800 мс замороженного цикла.
• Синхронный crypto — bcrypt.hashSync при реалистичном cost factor блокирует примерно 200–400 мс на вызов; под нагрузкой логина одна эта строка обрушивает пропускную способность. Хеширование, crypto.pbkdf2Sync, большой gzipSync.
• Катастрофический regex (ReDoS) — паттерн с вложенными квантификаторами вроде /A(B|C+)+D/ против специально подобранной строки может откатываться экспоненциально; один задокументированный случай потратил ~3,7 секунды чистого CPU на одном входе. Поскольку это на потоке цикла, атакующий может заморозить весь сервер одним запросом — отказ в обслуживании.

Лаг цикла: увидеть это раньше пользователей

Не нужно ждать жалоб на таймауты, чтобы найти блокировку. Прямой сигнал — лаг event loop (он же event-loop delay): запланируй таймер на t мс и замерь, насколько поздно он реально сработал. Если setTimeout(fn, 0) стабильно бежит на 200 мс позже, цикл был занят 200 мс — это опоздание и есть блокировка, в числах. Node даёт perf_hooks.monitorEventLoopDelay() для гистограммы (p50/p99 лага), а инструменты вроде clinic.js выводят это; обычный продакшен-порог алерта — около 100 мс лага.

Мысленный тест

Прежде чем любая строка выполнится на потоке цикла, старший рефлекс — один вопрос: это ограничено и быстро или может бежать десятки миллисекунд на большом входе? Прочитать 2 КБ конфига синхронно на старте — нормально. Парсить произвольный пользовательский JSON неизвестного размера, хешировать пароль или сопоставлять пользовательскую строку с откатывающимся regex на пути запроса — нет; этому место вне цикла, что и есть следующий урок.