OOM issue

[dotlineX]

I get the following issue while running the main index.

VERSION V0.3.2
checking db
(node:2631) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
current_height: 840181
current_transfer_height: 840181
current_ord_number_to_id_height: 840181
current_content_height: 840181
ord version: opi-ord 0.14.0-4

{}

<--- Last few GCs --->

[2631:0x5d11130]    26047 ms: Mark-Compact 3912.7 (4142.3) -> 3909.4 (4142.0) MB, 837.57 / 0.00 ms  (average mu = 0.142, current mu = 0.007) allocation failure; scavenge might not succeed
[2631:0x5d11130]    26935 ms: Mark-Compact 3911.5 (4143.1) -> 3910.0 (4142.8) MB, 884.50 / 0.00 ms  (average mu = 0.079, current mu = 0.003) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xb84bd6 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0xefec30 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0xefef17 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x1110925  [node]
 5: 0x1110eb4 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
 6: 0x1127da4 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) [node]
 7: 0x11285bc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 8: 0x10fe8c1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0x10ffa55 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0x10dc176 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
11: 0x10cdda4 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [node]
12: 0x10d10b7 v8::internal::FactoryBase<v8::internal::Factory>::NewRawTwoByteString(int, v8::internal::AllocationType) [node]
13: 0x1420925 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [node]
14: 0x1523f3c v8::internal::RegExpImpl::IrregexpExec(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSRegExp>, v8::internal::Handle<v8::internal::String>, int, v8::internal::Handle<v8::internal::RegExpMatchInfo>, v8::internal::RegExp::ExecQuirks) [node]
15: 0x154ad2d v8::internal::Runtime_RegExpExec(int, unsigned long*, v8::internal::Isolate*) [node]
16: 0x7f653fed9ef6
Aborted (core dumped)

The server has 128 GB of RAM and looking at htop while trying to run it does not show any major memory use.

What could lead to this problem?

Thanks

[samedcildir]

Hello,

Can you try to run the main_index with node --max-old-space-size=8192 .\index.js this command? By default node limits memory usage to around 4GB and it may not be enough for the indexer

[dotlineX]

Thanks for your reply.

With the given command I still get the same heap out of memory error.

[samedcildir]

Hello, it seems like you're using an old version (VERSION V0.3.2), the latest version is V0.4.1. The best way forward would be to update your client and reindex or restore from our backups using restore script.

The issue you're having is probably due to an error in main_index or ord client which made ord to reindex the same block over and over. When this happens, the file that js has to read becomes too large and may give out-of-memory errors. A possible way to fix it to check the log_file.txt which is next to ord binary. This file should have repeating block_start commands for the same block. You can safely remove all commands between two block_starts which does not have a corresponding block_end.

However, your client version is currently not supported and also does not conform to the latest updates to BRC-20, so I suggest updating your client.

[dotlineX]

I tried the update instructions on the README but that didn't change the version.

I re-cloned the repo and did a reinstall, but the version number is still V0.3.2

Looking deeper into the release 0.4.1 archive, the console.log("VERSION V0.3.2") is hardcoded.

After the reinstall I still get the same out of memory error, even though the server its running on has 128GB of RAM available

[samedcildir]

Sorry, I forgot to change that part, will update soon.

Can you check the file size of log_file.txt. It should be next to ord binary. If it is too high, it needs recovery. The easiest way would be to reindex (via restore script). If you don't want to reindex, then the file should be corrected using the method I've explained in the last comment.

[dotlineX]

Alright the log_file.txt was indeed very large, around the +30GB range.

I ran the restore instructions and it now seems to be working.

Thank you for the help!