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
Мобильное приложение для прослушивания музыки

Категория: #приложение
Язык: #en

https://dribbble.com/shots/23313341-Melody-Music-App-Design
Иллюстрации с очень комфортным и теплым вайбом
Дизайн упаковки для пива с фруктовыми экзотическими вкусами Carlton Dry.

Дизайн: WhatCameNext

#упаковка
Forwarded from Daily Coding 🔥
🛠 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 в долгоживущих процессах с интенсивным выделением буферов, которая лечится нормальными паттернами управления памятью и проектированием потоков.