Rosetta-bitcoin fails to set up during the indexing

Hi!

I have an AWS instance with 15GB of RAM, 243GB of storage and an 8-core CPU, ubuntu 18.04 bionic. Docker 20.10.8, the latest image of rosetta-bitcoin (v0.0.9).

Trying to set up the Testnet3 rosetta-bitcoin following the instructions and recommendations from the github and the blog.

After the node synchronises all blocks, the indexing is going with interrupts (at some moments the container dies with no logs about the error). I’ve checked the RAM and free space in real-time: there is no overuse at the moment of the container failure. Here is a screen recording video of how it dies. And the screenshot of the dead container’s latest logs.

That is strange. Please give me any suggestions about where to find an error.

UPD: updated sharing options of the record and the screenshot

1 Like

Hi @seva_gul

Welcome to the Rosetta community and thanks for raising this. We are looking into this and will get back to you soon.

1 Like

Hi @seva_gul ,

Do you still have the debug_log file(bitcoin-data/bitcoind/testnet3/debug.log) stored in your aws instance by any chance? if so, have you checked it yet or do you mind sharing it with us?

Thanks!

Hi @mai-li !

Yes, here is the debug file

Thanks!

Hi @seva_gul ,

We have tested rosetta-bitcoin(v 0.0.9) on 2 different AWS instances, one is 8-core 15GB RAM, and the other is 16-core 32GB RAM. The one running on 32GB instance can run perfectly without any unexpected interrupt, however the one running on 15GB instance is very likely to die after syncing up to 1350000+ block height.

We compared the memory usage of two instances during runtime, after syncing up to 1300000 block height, the memory usage of 15GB one is almost full(~14GB) while the memory usage of 32GB one is up to 22GB.

We have also witnessed when the memory usage hit the peak around ~14.3GB(on the 15GB instance), the syncing process would die. So we assume the unexpected interrupt of syncing might come from memory drain. We suggest to run rosetta-bitcoin again in an instance with larger memory and monitor the memory usage during runtime. Please let us know if this issue appears again. In the meanwhile, we will also do more checks on our side to see if there is any possible improvement we can do.

Thanks!