Sync Time

[martindale]

I'm syncing a new node with mainnet, on modern hardware (6 cores, i9-9900K CPU @ 3.60GHz), achieving approximately 400 blocks per minute. This seems excessively slow, at about 75 days to sync up to the latest block (~720,000).

Are there additional configuration options that can be used to speed this up, or is this something that needs further optimization?

[micahriggan]

From what I remember, the disk write speed is usually the limiting factor.

Your mongodb should be saturated with as many write operations as it can handle.

Depending on your usecase, there may be indexes that you can disable, which would reduce the amount of work as well.

[martindale]

I saw in the documentation that txindex is set to 0 — usually, I'd expect Bitcoin to handle the indexes, so perhaps toggling this to 1 may help?

edit: iotop shows ~50K/s read/write, so I don't think disk io is the bottleneck here. :/

[micahriggan]

Ah that sounds like something is messed up. It should be pushing in the megabytes

You don't need txindex because it syncs the blocks directly, and indexes the txs in mongo

Does the mongo logs say any repeating messages, or warnings about slow queries?

Is the bitcoin node hosted on the same box as bitcore, or are you pulling blocks from a remote host?

[swtrse]

Personally I struggled with Sync performance too. In my experience the limiting factor here is mongodb. You can try running mongodb on a dedicated machine. I have an instance running on an 8 Core with 32 GB Ram and played a bit with the mongodb settings to get at least decent performance. Here is a part of my config containing the relevant parts (the wiredTiger settings)

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  logRotate: reopen
  path: /var/log/mongodb/mongod.log

# Where and how to store data.
storage:
  dbPath: /databases/mongo
  journal:
    enabled: true
# engine:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 24

The problem is mongodb starts out fast >2000 blocks per second but that goes down to 3 blocks if mongodb needs to regenerate the indexes. If the index are not generated you can have 20-200 blocks per second on my machine.

I read lots of articles about mongodb and how to set it up that I can say. HW requirements for a setup that has a stable performance is just insane. Also I came to the conclusion that mongodb is in fact the wrong type of database for that kind of usage. Most articles I came around state that to get the most out of mongodb you have to ensure that the collection you are working with had to be in the RAM. With the size of the data we are talking here this is not possible therefore mongodb must write the data to the disk. Since most articles I found state that mongodb is designed an an inMemory Database writing to the disk is a really costly thing for mongodb and the performance drops significantly.

PErsonaly I do not understand why for this usecase it has to be mongodb (probably because it was cool at the time of writing). Since the data did not change in structure and the datafields are fixed for each collection there is no real need for a nosql solution. I think that a relational Database like postgres would perform and handle memory and indexes much better in this use case than mongodb. However since I have not the time to test that thoughts by writing an postgres or mysql backend for bitcore-node this is only speculative and out of the question for now.