🛠 Pome — это панель мониторинга метрик PostgreSQL для отслеживания работоспособности вашей базы данных. Этот проект находится на очень ранней стадии разработки, и в нем еще много недоработок, но я надеюсь, что смогу быстро его доработать. Подробнее о том, почему я решил создать Pome, можно прочитать здесь

🌍 Сайт

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

⁣Когда нет утечки, а OOM приходит: дефрагментация кучи V8

Внезапные Out of Memory в долгоживущих Node.js-процессах при работе с буферами и стримами — частая проблема в production, особенно при файловой обработке или проксировании данных. Разработчики ищут утечки, но код часто чист — настоящая причина скрыта в фрагментации Old Space кучи V8.

Как выглядит изнутри

Интенсивная работа с Buffer.alloc, Buffer.concat и стримами создает непрерывный цикл выделения и освобождения памяти. Со временем живые объекты оставляют мелкие "дыры" в Old Space. GC отлично собирает мусор, но не может дефрагментировать неподвижные объекты в старом пространстве. Результат — FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed, хотя суммарно свободной памяти ещё много.

Production-oriented пример

Рассмотрим типичный стрим для обработки данных:

const { Readable } = require('stream');
let data = Buffer.alloc(0);
const stream = new Readable({
  read(size) {
    data = Buffer.concat([data, Buffer.alloc(1024)]);
    this.push(Buffer.alloc(1024));
  }
});
stream.on('data', () => {});

Каждый вызов Buffer.concat создает новый буфер, старый закрепляется в памяти. Через часы работы — OOM при попытке выделить следующий буфер.

Типичная ошибка

V8 не гарантирует дефрагментацию: GC двигает объекты только в Young Generation, а буферы как внешние ресурсы дополнительно блокируются в Old Space. Усложняет ситуацию objectMode в стримах — он генерирует тысячи мелких объектов, ускоряя фрагментацию.

Практические советы

* Используйте пулы буферов — переиспользуйте через Buffer.allocUnsafe с ручным обнулением или свой pool.
* Ограничьте --max-old-space-size — это не панацея, но даёт запас до падения.
* Отключайте objectMode, если он не критичен — он создает избыточные объекты.
* Применяйте stream.pipeline вместо ручного управления для снижения накопления мусора.
* Мониторьте heapStats: стабильный рост malloced_memory с does_zap_garbage — явный признак фрагментации.

Вывод:
Дефрагментация кучи V8 — редкая, но реальная причина OOM в долгоживущих процессах с интенсивным выделением буферов, которая лечится нормальными паттернами управления памятью и проектированием потоков.

Sound Surround - Analog Synthesizer Shop

Day 30:
DeSo  The Decentralized Social Blockchain.
→ www.deso.com

Ivan Zviahin Product designer and design leader who is trying to shift the user's engagement in Tinkoff app.
→ ivanzviahin.by

The Power Plant Contemporary Art Gallery Toronto.
→ thepowerplant.org

More on
→ curated.design

🛠 BaguetteBox - это библиотека на основе JavaScript для создания адаптивных галерей лайтбоксов. Она очень легкая, доступна для мобильных устройств, проста в использовании и настройке и использует CSS3-переходы для плавных переходов изображений.

🌍 Сайт

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

⁣Скрытые убийцы Event Loop: ICU и Regex в Unicode-строках

Многие знают, что JSON.parse или fs.readFileSync блокируют Event Loop. Но есть враги похитрее - синхронные вызовы ICU и регулярных выражений на unicode-строках. Типичная ошибка: разработчики не подозревают, что методы нормализации или unicode-регулярки могут висеть десятки миллисекунд, оставаясь незамеченными до production-нагрузки.

Где прячется ICU
ICU тихо сидит в методах:
* String.prototype.normalize()
* String.prototype.toLocaleLowerCase()
* Intl API

Регулярки с флагами /u или /s на больших строках (эмодзи, иероглифы) могут висеть синхронно десятки миллисекунд. И ты даже не сразу поймешь, почему твой сервер тупит.

Пример скрытой блокировки

const hugeText = '🦄'.repeat(100000);
const start = performance.now();
hugeText.normalize('NFC'); // ICU молча обрабатывает 100к символов
console.log(Блокировка: ${performance.now() - start}ms);

Как профилировать
* Используй --prof флаг Node.js, потом node --prof-process.
* Разбрасывай логи с performance.now() до и после подозрительных операций.
* Clinic.js: npx clinic doctor -- node app.js

Как устранять

Для ICU:
* Выноси нормализацию в Worker Threads
* Режь на чанки по 1000 символов, обрабатывай порциями
* Предобрабатывай данные на этапе загрузки, а не в рантайме

const { Worker } = require('worker_threads');
const worker = new Worker('./normalize-worker.js');
worker.postMessage(hugeText);

Для RegExp:
* Типичная ошибка: паттерны с backtracking, например (a+)+b. Меняй на a+b.
* Попробуй re2 - без backtracking, работает предсказуемо
* Разбивай строку через string.slice, если можно

const safePattern = /^[a-z]+$/u;

Практический совет
Используй monitorEventLoopDelay() из perf_hooks - он показывает задержки Event Loop в наносекундах. Запусти его в фоне и сравнивай с пиками нагрузки.

Вывод: ICU и unicode-регекспы выглядят безобидно, но регулярно просаживают производительность - профилируйте их отдельно под нагрузкой, а не только в изолированных тестах.

Дизайн упаковок овсяных каш Quite Nice.

Дизайн: Herefor Studio

#упаковка