DevNotes Live
6 subscribers
84.2K photos
12K videos
195 files
35.4K links
Автоматический агрегатор IT ресурсов в Telegram (@devnotes_robot)
Информация: https://t.me/devnotes_live/121
Download Telegram
Starvation в worker_threads: почему libuv заставляет ваши воркеры голодать при смешанной нагрузке I/O и CPU

Когда вы смешиваете I/O и CPU-bound задачи в worker_threads, неочевидная деталь может убить производительность. В production часто встречается ситуация: воркеры простаивают, хотя ядра свободны. Корень проблемы - приоритеты очередей libuv.

Как libuv ест процессорное время воркеров
У libuv есть I/O callback queue с высоким приоритетом. Если в главном потоке активны I/O операции (чтение файлов, сетевые запросы), они обрабатываются первыми. Worker_threads получают CPU только на этапе idle. В результате воркер может ждать 100-200 мс при реальной нагрузке, даже если на ядрах нет другой работы.

Диагностика: ловим задержки
Начните с event loop lag. Вот production-ready пример:
const { performance } = require('perf_hooks');
const start = performance.now();
setTimeout(() => {
const lag = performance.now() - start - 100;
if (lag > 50) console.warn(Event loop lag: ${lag.toFixed(2)}ms);
// Если lag растет - воркеры голодают
}, 100);

Также полезно смотреть process._getActiveHandles() - там видно, какие задачи висят в libuv. Типичная ошибка: думать, что раз воркер в отдельном потоке, он не зависит от I/O в главном.

Четыре способа исправить
1. Ограничьте частоту I/O в главном потоке. Не спамьте readFile каждые 10 мс - используйте debounce или batch.
2. Разбивайте данные на чанки с setImmediate(). Это перераспределяет приоритет очереди libuv и дает воркерам больше шансов:
function processChunks(data) {
const chunk = data.splice(0, 100);
if (chunk.length) {
setImmediate(() => processChunks(data));
}
}

3. Настройте UV_THREADPOOL_SIZE. Не ставьте максимальное значение - обычно достаточно os.cpus().length * 2, но не больше 4.
4. Выделите одно ядро главному потоку: workerCount = os.cpus().length - 1.

Важный предостережение
Даже с настройками worker_threads остается зависимым от главного event loop. Если не изолировать CPU-bound и I/O задачи в разные процессы, при пиковой нагрузке воркеры все равно будут ждать. Планирование завязано на libuv - не игнорируйте это.

Вывод: Причина starvation не в worker_threads, а в неявных приоритетах libuv - решайте её через контроль I/O в главном потоке и разбивку задач с setImmediate.
Фейк-вакансии: почему в ответ тишина? 🤐

Статья расскажет о том, как распознать "призрачные" вакансии, которые могут быть обманом для молодых специалистов. Не пропустите!

Читать на дизайнерс | #статья
Резюме

А у меня же много лидов дизайна и директоров по исследованиям? Есть резюме специалиста по доступности

"я ищу работу в сфере цифровой доступности, вот резюме — https://career.habr.com/kamunicorn"

Работала в РТЛабс (разработчик портала Госуслуги), до этого написала курс по веб-доступности для HTML Academy
Странные паттерны
Капиллярная чашка НАСА — это чашка для условий невесомости, разработанная астронавтом НАСА Дональдом Петтитом на Международной космической станции. Это открытая питьевая чашка, предназначенная для использования в условиях микрогравитации. Она появилась благодаря желанию Петтита пить воду в космосе без пакета и трубочки.
Основная идея в том, что для того, чтобы отказаться от трубочки, нужно создать внутренний угол чашки, который создает мощное поверхностное натяжение жидкости. Напиток естественным образом притягивается к острому краю и удерживается там, не разлетаясь по космическому кораблю.

https://www.rit.edu/vignellicenter/product-timecapsule/nasa-capillary-cup

При этом всегда понимал, что подобного рода вещи в значительной степени фейк, направленный на характерный маркетинг - космические ручки и тд и тп, вплоть до космических штанов для секса - в значительной степени создавались под влиянием маркетинга - запусти в космос продукт и готовая реклама.
Forwarded from Daily Coding 🔥
🛠 Zoomove - плагин для jQuery, который позволяет динамически масштабировать изображения при наведении курсора мыши. Он прост в установке и использовании и обладает рядом свойств, с помощью которых можно задать URL-адрес изображения, размер масштабирования и положение курсора. Он совместим с Chrome 42+, Firefox 41+, Safari 9+, Opera 29+ и IE 9+.

🌍 Сайт

Daily Coding #инструменты & Max
Айдентика для компании аксессуаров для дальнобойщиков - «КАТЕГОРИЯ Е»

«КАТЕГОРИЯ Е» — это компания, которая производит аксессуары для дальнобойщиков, концентрируясь на том, чтобы привнести уют в их тяжелый быт.

: Борис Заборский
process.nextTick: невидимый убийца event loop, который кладет production-сервисы

Кажется, что все знают про process.nextTick, но на практике я регулярно вижу, как он валит продакшен. Проблема в том, что он имеет высший приоритет в микротаск-очереди и выполняется до любого I/O и таймеров. Это делает его опасным при рекурсивном использовании.

Как рекурсивный nextTick убивает таймеры

Event loop после каждого макротаска вычищает все микротаски. process.nextTick — микротаск с наивысшим приоритетом. Рекурсия без выхода блокирует очередь:

function recursiveTick() {
process.nextTick(recursiveTick);
}
recursiveTick();


После первого макротаска event loop заходит в микротаски. Там recursiveTick добавляет новый nextTick. И так бесконечно. setTimeout и setInterval не запускаются — они в макротасках, а микротаски не кончаются.

Production-кейс с кэшем и БД

У нас система с кэшем при ошибке доступа к БД в nextTick крутила переинициализацию соединения. В ошибочном сценарии — рекурсия. Результат: health-check’и молчали (таймеры не работали), входящие запросы висели, сервис падал веером. Типичная ошибка — думать, что nextTick безопасен для retry-логики.

Практические решения

* Никогда не используйте рекурсивный nextTick. Вместо него setImmediate — он ставит задачу в следующую фазу event loop, давая I/O и таймерам шанс:

function safeRecursive() {
// логика
setImmediate(safeRecursive);
}


* Если очередь нужна, добавьте лимит итераций. После, скажем, 1000 вызовов — принудительный yield через setTimeout(fn, 0).

* Для длинных цепочек используйте библиотеки для backpressure, иначе даже без бесконечной рекурсии производительность упадет.

Вывод:
process.nextTick ломает кооперативную природу event loop, и даже короткая рекурсия может полностью парализовать I/O и таймеры в production.
Forwarded from Dezzigners
This media is not supported in your browser
VIEW IN TELEGRAM
🧰 Tooltip Creator — поможет быстро добавить комментарии и подсказки поверх готовых экранов

Dezzigners
Терапия, которая реально помогает, а не вот это вот все 🧠
Please open Telegram to view this post
VIEW IN TELEGRAM