Syncing geth 1.9.15 took too long on HDD raid-0

Question

I've been running full node on a server with this config:

• Centos 7
• 11 Tb hdd raid-0
• 32 Gb ram

and I'm using geth 1.9.15-stable-0f77f34b

I'm trying to be archive node but syncing took over 1 months despite I had database dumps since january but after one month I still stucked in january blocks. So I don't think that I could ever finish syncing. I even tried --syncmode = full and that did not help neither.

Status of HDDs:

And it's R/W speed:

command:    
    hdparm -Tt /dev/sda4

result:

  /dev/sda4:
  Timing cached reads:   25122 MB in  1.99 seconds = 12633.44 MB/sec
  Timing buffered disk reads: 786 MB in  3.00 seconds = 261.86 MB/sec
———————————
command:
  sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync

result:
   1024+0 records in
   1024+0 records out
   1073741824 bytes (1.1 GB) copied, 0.648344 s, 1.7 GB/s

Also .ethereum folder size is about 3.6T right now.

How can I speed up this or is it ever possible to finish syncing with this server?

Answer 1

You need to use an SSD.

Q: Wait, so I can’t run a full node on an HDD?

A: Unfortunately not. Doing a fast sync on an HDD will take more time than you’re willing to wait with the current data schema. Even if you do wait it out, an HDD will not be able to keep up with the read/write requirements of transaction processing on mainnet.

You however should be able to run a light client on an HDD with minimal impact on system resources. If you wish to run a full node however, an SSD is your only option.

From the Geth FAQ expanded in related answer about fast sync.

Answer 2

you can sync even with hdd, but you need to provide more memory and play around with the cache parameter - some values are optimized for syncing, some are better, if you like to run an archive node - depends on what you have in mind. By default geth will use 4GB memory for caching, which means there's quite some disc activity. With the --cache parameter you can allovate more and use more of the available system resources. Those default parameter are more meant for Azure or AWS cloud instances, not bare metal server. So startup parameter need to be tuned. However, even with more memory, syncing takes longer with HDD, compared to SSD, but it's not impossible. Looking into the future - if the storage problems are not solved soon (compare blockchain size Ethereum vs Bitcoin or others), as soon as mass adaption starts, the whole system will collapse.