prisma: Get `JavaScript heap out of memory` error when pushing a bulk date with `createMany`.
Bug description
I’m working on migrating data form mariaDB to postgreSQL.
When I try to push a bulk data with createMany, I got error message like below.
The ballpark data size I’v tried is about 252mb.
<--- Last few GCs --->
[94783:0x120008000] 645373 ms: Scavenge 4031.5 (4114.0) -> 4029.3 (4117.5) MB, 6.5 / 0.0 ms (average mu = 0.874, current mu = 0.271) allocation failure
[94783:0x120008000] 645387 ms: Scavenge 4034.7 (4117.5) -> 4032.1 (4135.5) MB, 7.2 / 0.0 ms (average mu = 0.874, current mu = 0.271) allocation failure
[94783:0x120008000] 646371 ms: Mark-sweep 4044.7 (4135.5) -> 4038.1 (4145.2) MB, 967.5 / 0.0 ms (average mu = 0.814, current mu = 0.109) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
1: 0x10476c668 node::Abort() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
2: 0x10476c7e8 node::errors::TryCatchScope::~TryCatchScope() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
3: 0x1048b77e8 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
4: 0x1048b777c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
5: 0x104a4a214 v8::internal::Heap::CollectionBarrier::ShutdownRequested() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
6: 0x104a9bc6c v8::internal::EvacuateNewSpaceVisitor::Visit(v8::internal::HeapObject, int) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
7: 0x104a85214 void v8::internal::LiveObjectVisitor::VisitBlackObjectsNoFail<v8::internal::EvacuateNewSpaceVisitor, v8::internal::MajorNonAtomicMarkingState>(v8::internal::MemoryChunk*, v8::internal::MajorNonAtomicMarkingState*, v8::internal::EvacuateNewSpaceVisitor*, v8::internal::LiveObjectVisitor::IterationMode) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
8: 0x104a84e6c v8::internal::FullEvacuator::RawEvacuatePage(v8::internal::MemoryChunk*, long*) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
9: 0x104a84b70 v8::internal::Evacuator::EvacuatePage(v8::internal::MemoryChunk*) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
10: 0x104a9fcf0 v8::internal::PageEvacuationTask::RunInParallel(v8::internal::ItemParallelJob::Task::Runner) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
11: 0x104a5ffbc v8::internal::ItemParallelJob::Task::RunInternal() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
12: 0x104a6038c v8::internal::ItemParallelJob::Run() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
13: 0x104a8693c void v8::internal::MarkCompactCollectorBase::CreateAndExecuteEvacuationTasks<v8::internal::FullEvacuator, v8::internal::MarkCompactCollector>(v8::internal::MarkCompactCollector*, v8::internal::ItemParallelJob*, v8::internal::MigrationObserver*, long) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
14: 0x104a864e4 v8::internal::MarkCompactCollector::EvacuatePagesInParallel() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
15: 0x104a736b4 v8::internal::MarkCompactCollector::Evacuate() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
16: 0x104a71478 v8::internal::MarkCompactCollector::CollectGarbage() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
17: 0x104a4a878 v8::internal::Heap::MarkCompact() [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
18: 0x104a48154 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
19: 0x104a461f0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
20: 0x104a524b8 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
21: 0x104a52548 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
22: 0x104a2588c v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
23: 0x104d42038 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
24: 0x1050321cc Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
25: 0x1050331fc Builtins_StringAdd_CheckNone [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
26: 0x10508d000 Builtins_RegExpReplace [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
27: 0x1050232b0 Builtins_StringPrototypeReplace [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
28: 0x203a5e9f1fc
29: 0x10504ea24 Builtins_ArrayMap [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
30: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
31: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
32: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
33: 0x104fc2504 Builtins_ArgumentsAdaptorTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
34: 0x10504ea24 Builtins_ArrayMap [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
35: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
36: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
37: 0x1050650a0 Builtins_OrdinaryToPrimitive_String [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
38: 0x105064df0 Builtins_NonPrimitiveToPrimitive_String [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
39: 0x10505e4b4 Builtins_ToString [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
40: 0x105060a0c Builtins_StringConstructor [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
41: 0x10504ea24 Builtins_ArrayMap [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
42: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
43: 0x1050650a0 Builtins_OrdinaryToPrimitive_String [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
44: 0x105064df0 Builtins_NonPrimitiveToPrimitive_String [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
45: 0x10505e4b4 Builtins_ToString [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
46: 0x105060a0c Builtins_StringConstructor [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
47: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
48: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
49: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
50: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
51: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
52: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
53: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
54: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
55: 0x104fc2504 Builtins_ArgumentsAdaptorTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
56: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
57: 0x104fcaed4 Builtins_InterpreterEntryTrampoline [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
58: 0x10507fc4c Builtins_PromiseResolveThenableJob [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
59: 0x104fea274 Builtins_RunMicrotasks [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
60: 0x104fc8668 Builtins_JSRunMicrotasksEntry [/Users/dean/.nvm/versions/node/v15.9.0/bin/node]
61: 0x120008000
error Command failed with signal "SIGABRT".
How to reproduce
Expected behavior
pushing data without error.
Prisma information
Try to push data to below model.
generator client {
provider = "prisma-client-js"
output = "../src/generated/client-new"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Artwork {
id String @id @default(cuid()) @db.VarChar(50)
productionFromYear String? @db.VarChar(4)
productionToYear String? @db.VarChar(4)
korName String? @db.VarChar(700)
engName String? @db.VarChar(700)
meterial String? @db.Text
dimension String? @db.Text
heightType String? @db.VarChar(50)
heightCm Decimal? @db.Decimal(7, 3)
widthCm Decimal? @db.Decimal(7, 3)
depthCm Decimal? @db.Decimal(7, 3)
diameterCm Decimal? @db.Decimal(7, 3)
heightInch Decimal? @db.Decimal(7, 3)
widthInch Decimal? @db.Decimal(7, 3)
depthInch Decimal? @db.Decimal(7, 3)
diameterInch Decimal? @db.Decimal(7, 3)
desc String?
modifierId String? @db.VarChar(50)
registId String? @db.VarChar(50)
locationLat Decimal? @db.Decimal(15, 12)
locationLon Decimal? @db.Decimal(15, 12)
estimatedPriceCurrency String? @db.VarChar(50)
highEstimatedPrice Decimal? @db.Decimal(20, 5)
lowEstimatedPrice Decimal? @db.Decimal(20, 5)
estimatedPriceUSD Decimal? @db.Decimal(20, 5)
estimatedPriceRegistDate DateTime?
signiture String? @db.VarChar(1000)
location String? @db.VarChar(200)
publicSalesRecordState String? @default("100") @db.VarChar(50)
publicSalesRecordPriceCurrency String? @default("100") @db.VarChar(50)
publicSalesRecordPrice Decimal? @db.Decimal(20, 5)
publicSalesRecordDate DateTime?
hashtag String? @db.VarChar(1000)
repColor1 String? @db.VarChar(50)
repColor2 String? @db.VarChar(50)
repColor3 String? @db.VarChar(50)
introUrl String? @db.VarChar(255)
sizeType String? @db.VarChar(50)
createdAt DateTime? @default(now())
updatedAt DateTime? @default(now()) @updatedAt
deletedAt DateTime?
artistId String? @db.VarChar(50)
artist Artist? @relation(fields: [artistId], references: [id])
essays Essay[]
comments Comment[]
likes Like[]
}
Environment & setup
- OS: Mac OS silicon(M1) Bigsur
- Database: PostgreSQL
- Node.js version: 15.9
Prisma Version
2.27
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 16 (8 by maintainers)
Commits related to this issue
- test: Add memory test for create many Unsuccesful attempt to reproduce leak, reported in #8500. Test uses smaller bathch size then reported for the execution time sake, but it does not reproduce wit... — committed to prisma/prisma by SevInf 2 years ago
- test: Add memory test for create many Unsuccesful attempt to reproduce leak, reported in #8500. Test uses smaller bathch size then reported for the execution time sake, but it does not reproduce wit... — committed to prisma/prisma by SevInf 2 years ago
- test: Add memory test for createMany (#15136) * test: Add memory test for create many Unsuccesful attempt to reproduce leak, reported in #8500. Test uses smaller bathch size then reported for t... — committed to prisma/prisma by SevInf 2 years ago
There are some improvements to memory consumption on the large queries. Re-running @mehdi-sp example, on 4.16.2 heap grows by 1977 MB after insert, where on 5.0.0 it grows by 555 MB. In both cases, excess memory is succesfully reclaimed by GC.
Hi @janpio …
Yes. I will try to explain below…
We have an application which imports 10 excel files, make some validations in their records e insert into a postgres db through prisma library.
We note that a process RSS memory increases and HEAP memory not. We use createMany() .
According to @mehdi-sp @kaykhancheckpoint (https://github.com/prisma/prisma/issues/8500#issuecomment-1040285909) we made any test: 1- prisma createMany or queryRaw show memory leak issue (createMany high, queryRaw medium). 2- When we remove prisma and use other library (pg - https://node-postgres.com/ ) the memory leak disappears.
Bellow results of some tests executed based on @mehdi-sp repo (https://github.com/mehdi-sp/prisma-createmany-outofmemory):
Prisma CreateMany RSS vs. Heap memory
Prisma QueryRaw RSS vs. Heap memory
No Prisma use (PG library - https://node-postgres.com/)
@janpio Recently we had the same problem while inserting ~1M rows using
the purple bar on the right of the picture is the input array(~400MB) and the green one on the left is the memory used by prisma client (~1400MB) before the crash.
https://github.com/mehdi-sp/prisma-createmany-outofmemory
createMany. from my observations it uses at least 3 times more memory than the size of its input.@janpio I finished off that job last year. So I don’t have a data anymore. I’m sorry that I can’t help you.