Open FreePhoenix888 opened 4 months ago
This is related to RAM, not disk.
I met this again when testing russian-laws
[1] <--- Last few GCs --->
[1]
[1] [4350:0x6ba5fe0] 15777233 ms: Mark-sweep 3481.2 (4143.9) -> 3473.0 (4133.4) MB, 3738.1 / 0.0 ms (average mu = 0.150, current mu = 0.040) allocation failure; GC in old space requested
[1] [4350:0x6ba5fe0] 15779337 ms: Mark-sweep 3473.0 (4133.4) -> 3473.0 (4131.4) MB, 2103.6 / 0.0 ms (average mu = 0.103, current mu = 0.000) allocation failure; GC in old space requested
[1]
[1]
[1] <--- JS stacktrace --->
[1]
[1] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
[1] 1: 0xb83f50 node::Abort() [node]
[1] 2: 0xa94834 [node]
[1] 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
[1] 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
[1] 5: 0xf42265 [node]
[1] 6: 0xf43168 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
[1] 7: 0xf53673 [node]
[1] 8: 0xf544e8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
[1] 9: 0xf56ad4 v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) [node]
[1] 10: 0xf3026d v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
[1] 11: 0xf10760 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
[1] 12: 0xf07d2c v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
[1] 13: 0xf07ea5 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
[1] 14: 0x11afb9d v8::internal::Handle<v8::internal::EphemeronHashTable> v8::internal::HashTable<v8::internal::EphemeronHashTable, v8::internal::ObjectHashTableShape>::New<v8::internal::Isolate>(v8::internal::Isolate*, int, v8::internal::AllocationType, v8::internal::MinimumCapacity) [node]
[1] 15: 0x11afe43 v8::internal::Handle<v8::internal::EphemeronHashTable> v8::internal::HashTable<v8::internal::EphemeronHashTable, v8::internal::ObjectHashTableShape>::EnsureCapacity<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::EphemeronHashTable>, int, v8::internal::AllocationType) [node]
[1] 16: 0x11b05f5 v8::internal::ObjectHashTableBase<v8::internal::EphemeronHashTable, v8::internal::ObjectHashTableShape>::Put(v8::internal::Isolate*, v8::internal::Handle<v8::internal::EphemeronHashTable>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int) [node]
[1] 17: 0x11b07eb v8::internal::JSWeakCollection::Set(v8::internal::Handle<v8::internal::JSWeakCollection>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int) [node]
[1] 18: 0x12cd490 v8::internal::Runtime_WeakCollectionSet(int, unsigned long*, v8::internal::Isolate*) [node]
[1] 19: 0x17035b9 [node]
[1] Aborted
[1] npm run deeplinks exited with code 134
Error
Description
3006 port is down now I have not seen this error before, but see now, when testing russian-laws and therefore creating a lot of links. Maybe gitpod disk is out of memory? If yes it is one more reason to integrate linksplatform with deep as fast as we can because those htmls are not too big (a few megabyes) and I have run test approximately 5-20 times
No, disk memory is not the reason, deep takes 10gb:
If I restart deep 3006 port will open: