After all night running, on nvme, a powerful CPU and with plenty of RAM, it took several hours to reach 65% and is stuck there. Now all peers are blocked for some reason and is not syncing anymore.
Command used:
```
monerod --data-dir /flash/monero/ --prune-blockchain --sync-pruned-blocks --db-sync-mode=fast:async:250000000 --fast-block-sync 1 --prep-blocks-threads 8 --block-sync-size 100 --max-concurrency 8 --no-igd --no-zmq --enable-dns-blocklist --out-peers 16 --in-peers 8
```
logs:
```
...
2026-02-17 07:54:36.217 I Host 95.217.7.137 blocked.
2026-02-17 07:54:36.217 I Host 95.217.7.248 blocked.
2026-02-17 07:54:40.113 E Too many object fields
2026-02-17 07:54:40.116 E Exception at [portable_storage::load_from_binary], what=Too many object fields
2026-02-17 07:54:41.609 E Too many object fields
2026-02-17 07:54:41.611 E Exception at [portable_storage::load_from_binary], what=Too many object fields
status
Height: 2365820/3611892 (65.5%) on mainnet, not mining, net hash 2.70 GH/s, v14, 16(out)+0(in) connections, uptime 0d 0h 0m 16s
```
All I want is to finish sync and measure the CPU time of validating transactions after the initial sync, to compare with bitcoind and see how it would scale.
Login to reply
Replies (2)
I take it back, you don't seem to be technically ignorant or a liar ๐
but I've never had a the Monero daemon hang like that.
You're running this locally, not a VPS right? what kind of internet do you have?
is /flash removable storage?
@shortwavesurfer2009
@Saberhagen The Nameless
You might want to sync without giving it too many parameters at first. Pruning will still need to download the whole chain.
I usually need something like one night to sync a new node, but I don't want to benchmark the process on my mediocre systems anyways.
You might want to push this to github to see if you discovered ba bug.