Лука Гаделия Концертирующий органист
Ссылка на проект

Поиск по теме:
#портфолио #музыка

Минималистичный брендинг

🛠 Atlas — это универсальный инструмент для управления и миграции схем баз данных с использованием современных принципов DevOps.

🌍 Сайт

Daily Coding #инструменты #DevOps & Max

Сатурация libuv thread pool в Node.js: как crypto, fs и dns.lookup ломают latency в production

В Node.js async не значит "без очередей": часть операций конкурирует за общий libuv thread pool. Частая ошибка в production - смотреть только на event loop lag и не видеть очередь внутри пула.

Где возникает проблема
По умолчанию UV_THREADPOOL_SIZE=4 на процесс. Туда попадают crypto.pbkdf2, scrypt, часть randomBytes, многие fs.*, dns.lookup, zlib.

for (let i = 0; i < 8; i++)
  crypto.pbkdf2(p, s, 500_000, 64, 'sha512', cb);

await fs.readFile('./config.json');
await dns.lookup('api.internal');

Первые 4 pbkdf2 занимают весь пул, остальные операции ждут. Маленький config-файл или DNS lookup внезапно дают сотни миллисекунд.

Production-сценарий
Логин считает password hash, HTTP-клиент часто резолвит hostname, а hot path читает сертификат или metadata с диска. CPU может быть не 100%, event loop - "здоровым", но p99 растет из-за очереди к worker'ам.

DNS-нюанс
dns.lookup использует системный resolver через getaddrinfo и libuv pool. dns.resolve4/6/Mx используют c-ares и не конкурируют с fs/crypto так же. Предупреждение: массовый dns.lookup легко принять за "медленную сеть".

Что делать
* выносить тяжелый crypto в worker_threads, отдельный сервис, процессы или queue;
* не читать файлы на hot path - грузить и кэшировать заранее;
* включать keep-alive, pooling и DNS cache;
* менять UV_THREADPOOL_SIZE только после load test:

UV_THREADPOOL_SIZE=32 node server.js

Больше thread'ов - не silver bullet: CPU-bound задачи могут ухудшить p99 из-за context switching.

Вывод:
libuv thread pool - маленький общий ресурс процесса, поэтому latency-sensitive I/O нельзя смешивать с тяжелым crypto и частым dns.lookup без изоляции и измерений.