Я работаю над проектом NodeJS, который использует sharp node package
для изменения размера изображений JPEG / JPG.
Проблема в том, что процесс Node продолжает добавлять обработанный файл в память и никогда не освобождает его.
В результате количество потребляемой памяти увеличивается с каждым запросом, и оно никогда не освобождается.
После отладки приложения я понял, что sharp toBuffer API вызывает проблему.
Я пытался использовать альтернативное решение, создав custom writable stream
и обмотав его sharp Duplex stream
, но в итоге он столкнулся с той же проблемой.
Я не понимаю, что я здесь что-то упускаю илиэто ошибка.
Совместное использование кода ниже (я удалил нежелательный код, чтобы сделать его компактным) -
const { Writable } = require("stream");
const { createServer } = require("http");
const { readFileSync } = require("fs");
const sharp = require("sharp");
async function resizeJpeg(input_buffer) {
// initialise file, the response object
const file = { normalisedImage: null, originalImage: null };
// initialise sharp instance using original image buffer
let image = sharp(input_buffer);
// set the original image metadata
file.originalImage = await image.metadata();
file.originalImage.quality = 85;
// generate buffer using sharp resize API with default quality & dimensions.
// ############### THIS IS WHERE MEMORY CONSUMPTION OCCURS ###############
// APPROACH 1 (SHARP toBuffer API)
const buffer = await image.resize(2000, 798).jpeg({ quality: 85 }).toBuffer();
// APPROACH 1 ENDS
// APPROACH 2 (CUSTOM WRITABLE STREAM)
// const buffer = await sharpToBuffer(image.resize(2000, 798).jpeg({ quality: 85 }));
// APPROACH 2 ENDS
// set resized image metadata
file.normalisedImage = await sharp(buffer).metadata();
file.normalisedImage.quality = 85;
return file;
}
// converts sharp readable stream to buffer using custom writable buffer
async function sharpToBuffer(readable) {
return new Promise((resolve, reject) => {
const writable = new WriteStream().on("finish", () => resolve(Buffer.concat(writable.bufferChunks)));
readable.pipe(writable);
});
}
// simple writable stream
class WriteStream extends Writable {
constructor() { super(); this.bufferChunks = [] }
_write(chunk, encoding, next) { this.bufferChunks.push(chunk); next(); }
}
createServer(async (request, response) => {
// ignore favicon calls
if (request.url.indexOf("favicon.ico") > -1) { return response.end(); }
// trigger resize call and pass buffer of original image file
const { normalisedImage, originalImage } = await resizeJpeg(readFileSync(`${__dirname}/30mb.jpg`));
// respond stringified json
response.end(
JSON.stringify({
normalisedImage: { size: normalisedImage.size, width: normalisedImage.width, height: normalisedImage.height, quality: normalisedImage.quality },
originalImage: { size: originalImage.size, width: originalImage.width, height: originalImage.height, quality: originalImage.quality }
}, null, 4));
}).listen(3000, () => console.log("server started"));
Как видите, resizeJpeg function
реализовал оба подхода.
Чтобы сделать это, вам просто нужно убедиться, что файл 30mb.jpg
существует в том же каталоге.
Используемое изображение доступно здесь
Inесли вы используете Linux, следуя top command
может использоваться для мониторинга использования памяти, если имя файла so.js
-
top ps -ef | grep 'so.js' | awk '{print $2}' | sed 's/.*/-p &/' | xargs echo -c