Backend: multer.memoryStorage holds 500 MB parts in RAM — concurrent uploads OOM the API #120
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixed in
04ce096.services/mam-api/src/routes/upload.jsnow usesmulter.diskStoragewriting toUPLOAD_TMP_DIR(defaults toos.tmpdir()/df-uploads)./partand/simplestream the on-disk file to S3 withfs.createReadStreamand unlink the tmp file infinally. Concurrent 500 MB uploads no longer hold their bytes in RAM.zgaetano referenced this issue2026-05-26 18:22:49 -04:00
Fix Plan — #120 multer.memoryStorage OOM on concurrent uploads
Root cause:
upload.jsandassets.jsusemulter.memoryStorage()with 500MB cap. Each concurrent upload chunk lives in heap. 3 operators × 4GB files = ~12GB → OOM.Fix — switch to disk storage + stream to S3:
Better: use
@aws-sdk/lib-storageUploadclass withcreateReadStream()for streaming multipart direct to S3.Files:
src/routes/upload.js,src/routes/assets.jsEffort: ~2h
**Priority: P1 — OOM risk