0

image

left side is instance(using google cloud platform) running nodeos, with below spec.

n1-standard-8 (vCPU #8, RAM 30GB, SSD 1TB)

using back-up block from https://eosnode.tools/blocks

mongodb-queue-size = 4096

mongodb-api-cache-size = 10240

filter-on = * / trying to make block explorer, so I need filter-on as *

right side is instance running mongodb, with below spec.

n1-highmem-4 (vCPU #4, RAM 26GB, HDD 1TB)

Currently my nodeos+mongodb is syncing 7516120 blocks (about 25% of mainnet). I think after about 500000 blocks, sync speed isn't catching mainnet's block generartion speed(1 sec = 2 blocks).

Is it normal??

Improve this question

2 Answers 2

Reset to default
1

nodeos syncing is very CPU intensive but mongo_db_plugin is even much more CPU and IO intensive.

I see you are using a cloud server for nodeos, which is very likely not performant enough. In my experience on AWS, the syncing speed was also slower than new block generation.

You should try a CPU enhanced instance, or more preferrably a bare-metal server for nodeos, and the higher the single-core CPU frequency, the better.

Improve this answer
0

From EOS 42 regarding the history/mongo plugin | Link: https://medium.com/@eos42/scalable-full-history-nodes-b4eccf113d57

Syncing and running a full history node in early November 2018 required roughly 800 GB of RAM. In less than one month, the history plugin now requires more than 1.5 TB of ram, nearly doubling in a matter of weeks! Using the history plugin to run a full history node now costs around 30k USD.

State History Plugin

Todd Fleming from Block.one has been developing another history solution called the State History Plugin. The state history plugin solves a number of the issues experienced with the MongoDB plugin:

  • Automatically handles forks and will not store any duplicated data.
  • The database storage is decoupled from Nodeos. Therefore, if the database goes down it can easily be synced without stopping Nodeos or requiring a replay of the blockchain.
  • Functionality that until now was not possible. Features include getting smart contract table contents at every block they are changed.
  • Any future schema changes won’t require a replay of Nodoes because of the decoupled design (note: this feature will be included in future updates).

in an effort to make the State History Plugin more accessible to everyone, EOS42 is teaming up with Block Matrix to offer daily snapshots of the State History data files, effectively allowing anyone to stand up a brand new history node in a matter of minutes instead of waiting weeks to sync.

Another article from Greymass covering the topic | Link: https://steemit.com/eos/@greymass/introducing-light-history-nodes-for-eos

The state of History API nodes on the EOS network is a growing concern. While we are all exploring long-term solutions, such as our recent sponsorship of the development of a new History Plugin, in the interim, problems continue to arise.

And one more from EOS Asia "EOS Asia’s History API Announcement": https://medium.com/@eosasia/eos-asias-history-api-announcement-db6e66de97e7

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.