Bitcoin Forum

I have a fairly robust dedicated pc running ubuntu:
Processor Intel Core i5
Memory 8gb
Disk 500 gb ssd

The progress started quickly with about 70% in a couple of days.  Then it slowed down dramatically to where now  like today for example it has downloaded not even 1% in the last 12 hours, maybe getting like 2% per day at this point.

Been checking to debug.log no errors, running continuously with percentage complete increasing as expected (just slow). 
Config:
prune=3000
dbcache=16384

Looking for any suggestions to try out.  Seems like at this rate it would take a few weeks to load, that seems too slow, or it this how long it seems to take nowadays?

1) I5 is a bit vague. The original Intel Core i5 was released almost 15 years ago. What gen is yours?

2) The 500 GB drive is not large enough you need at least 1 TB now. https://www.blockchain.com/explorer/charts/blocks-size

3) How fast is your connection? Downloading 540GB on a 1M connection is still going to take a while no matter what else you have.

-Dave

It seems that you set the dbcache more than your current RAM memory size since you have 8GB of memory you shouldn't set it to more than 4096MB.

I suggest try to change it to 4096 but before you do that make sure to stop the syncing process first if you are using a GUI just exit the GUI, and it will shut down automatically if not you can use "bitcoin-cli stop" to avoid corruption reboot your PC and rerun everything then monitor it again if the syncing process still slow or not.

OP has prune=3000 in his bitcoin.conf, limiting his blockchain data to approx. 3GB. The directory of chainstate will still occupy ~12GB. Depending on how full the 500GB drive is with other stuff, it should still suffice.

You're correct when you speak of an unpruned, full archival, node which needs 611GB for the blockchain data alone. Here's my current storage usage:

As BitMaxz already pointed out, dbcache is way too large for only 8GB RAM. Use approx. half the RAM for dbcache. For an Initial Blockchain Download (IBD) you can also set the option blocksonly=1, so that your node is not bothered with transaction verification and relay and mempool stuff.

Intel® Core™ i5-3470T CPU @ 2.90GHz × 4


OK, good info, thanks

Just did a test, down = 197.94 Mbps, wired fiber

Thanks, great suggestion.  I will do this.  I am running the bitcoind as a systemd service and am able to gracefully shut it down and restart it.

OK, thanks, that tracks what I thought.

So just as an update, I am running the bitcoind as a systemd job.  I also have a crontab job to track hourly the progress.  The internet speed is at some times better than others.  I get between .03% and .15% per hour of progress.

I will update the cache parameter setting and retry.  

[I updated dbcache=4096 and will continue to monitor progress hourly, and update here after a while, thanks all, number one priority on my list to get this working:)]

How is your memory load? My guess is you've reached the part where your SSD-speed (both reads and writes) is the limiting factor due to the low RAM. There's a huge difference between SSDs: some have very bad performance when it comes to combined reads and writes. If it's a budget SSD, that may be the cause.

On a similar setup, it took me less than 2 days to complete the IBD. See this post (https://bitcointalk.org/index.php?topic=5480200.msg63467209#msg63467209) on my progress.

Considering the low price of RAM, if at all possible, add some ;) That should make things run much smoother.

I have not used #free before but the numbers don't seem to look to bad and are similar to your outputs.  Still not explaining my slow times as far as I can tell. 


Also after updating the dbcache setting still ridiculously slow like .09% per hour.  Like 10 times too slow. 

Have a look at hard disk io/load. I forgot what I used exactly, but Google gives many options.

Quick (but inconclusive) test: how long does this take?

That new setting is fine.
Setting the database cache to 16GB while having 8GB of RAM is bad for your SSD since your system will be relying too much on page file.
Bitcoin Core use almost all of the allotted dbcache (about 15GB with your previous setting) to save the UTXO set to RAM before writing it on disk.
Since more than half is being moved from/to disk as page file, plus the data being dumped to the data directory,
your SSD must had been on a lot of strain before that could make IBD slower.
(apparent on HDD, not much on SSD, not on separate physical drives for OS and bitcoin datadir)

How about your peers? try: bitcoin-cli getpeerinfo
Is it populated with nodes with bad connections? Peers keep disconnecting? ('conntime' just recent)

shows a blank list.  I see continual but slow progress, does this indicate a problem that the list is blank?





not sure what this is showing me.

After thinking about it for a while my thinking at this point is I am getting somehow ISP throttled which fits the facts that initially I was seeing fairly normal progress.  It is being done in such a way as to not affect other activities I am doing on a separate computer.  

That outputs your list of peers, zero means that you're currently not connected to any Bitcoin node.
That must be the issue, low to zero peer means slow IBD since there's few/no node to download the blockchain from.

You must check your system for anything that blocks any connection to Bitcoin Core.
Start with your firewall.

I have a very slow HDD in my system. When doing the above, it can take minutes to sync. It it would be many seconds for your SSD, I would have called it bad. At 0.4s, I can't really tell. For an idle system it's a few ms.

That's easy to test: rename your Bitcoin Core directory and restart from scratch. If it's fast again, it's not your ISP.

I saved off the blocks, chainstate and debug.log and restarted.  Will know soon, good idea :)

To start with I see a bunch of peers in the getpeerinfo now....

I am confused.  So now at the start of running fresh it is quick again.

First hour = 4.18% which is good.

Not sure what is happening.

getpeerinfo still showing several peers.

Any clues or hints on why it would run fast at the beginning and then slow down?  I am not using a firewall.

Your chainstate directory gets bigger, and eventually doesn't fit your RAM anymore. That large increases the disk reads and writes. But still, about 10 times slower than mine shouldn't happen. What SSD do you have?

I started at the same rate:

500GB TOSHIBA MQ01ABF0

Interesting about the slow down under normal circumstances, makes sense.  I will see on this go round how progress is in a while.  I might get a 1000 mbps fiber dedicated separate line to troubleshoot further.

That's not an SSD, it's a HDD. That explains everything! It needs to write several TB of data, read a lot of data, and have random access all the time. My SSD was already the limiting factor, it makes total sense your HDD is a factor 10 slower.

Your internet connection isn't the bottleneck. There are only 2 things that can improve performance:
1. Get a SSD, preferrably a good brand (Samsung Evo for instance), not a budget disk. Check some reviews on Tom's Hardware to make sure you get a good one. But even a budget SSD will be much faster than your current HDD.
2. Add more RAM.

If you do both, you're entire computing experience will get much smoother. Without those upgrades, you should probably just use Electrum instead of Bitcoin Core.

an I 5  cpu
32gb ram
a 2tb ssd

and 200 or more internet

That's excessive for a pruned node.

Ohh... had to double check that.  It is in a ThinkCentre M92P.  Need an upgrade, thanks :)
Most stuff yes.  For this I am going to use JoinMarket once I get this stable.  I have it installed but haven't started using it yet.

Progress running after 13 hours this time around is 53.13%.

Google says it can handle 32 GB RAM. If that's correct, Bitcoin Core will even work fine with an HDD (I did it on a server recently).

I haver no experience with JoinMarket.

The thing is.... The first part isn't that hard on your hardware: your chainstate directory is probably still smaller than your available RAM. At the end of the IBD, it'll be 12 GB.

So I am doing a pretty extensive test on existing system as follows:
1.)  Save off previous chainstate, blocks (bitcoin-core db) and restart from 0.
2.)  Now noted that initial progress to 50% or so is good, normal.
3.)  Once it starts slowing down I am stopping the bitcoind.service for 12 hours, giving it a rest.  This is just in case there is some kind of weird throttling going on.
4.)  After rest period restarting bitcoind.service.
5.)  If slow, then I am going to order this -> Beelink SER5 MAX RYZEN 7 5800H Mini pc office + Ram32GB + Storage 1TB

It is looking like about to order it, just waiting to confirm that progress is now slow .....

The surprising aspect for me is normally things either work or they don't.  This is one of those particular things that becomes more and more resource consuming as it goes along, still working but going slower and slower.

OK just now:  hmmm, inconclusive.  First full hour after restart = .98%.  Total now at 70.58%. 

The first hour may had been spent discovering peers, syncing "block headers", then the first few blocks.
Normally it should be finished in a few minutes but if you keep on getting slow peers and limited to 11 (when no inbound peers), that could take a while.

That will even be inconsistent in the later blocks.
Take note that Bitcoin Core has a hard-coded "assumed valid" block which dictates to skip the script verifications from the blocks before it.
Means that it would take longer to verify blocks newer than that indicated blocks hash.
Each older versions of Bitcoin Core have lower block height than the newer versions but you can set it with assumevalid=<block_hash> setting or --assumevalid=<block_hash> arg.
Recommended to use the latest version's default (link (https://github.com/bitcoin/bitcoin/blob/a44b0f771f2130b89b608f39055a355693c91a8c/src/kernel/chainparams.cpp#L108)) if you're using an older Bitcoin Core version.

This step doesn't help.

That's more than sufficient to do a quick download.

Correct.

Actually when I said the first hour it is because I track from a crontab job each hour and before the first 'full' hour there was actually about 1/2 hour.

Still continuing to plug along, now at 74.59 doing just over 1% per hour. 

However another symptom of the system hardware being maxed out is now to do anything on the system I need to temporarily shutdown the bitcoind process.

So will report back after new hardware arrives and is set up. 

This was at the upper end of my hardware search, I am a bit annoyed I can't really find anything without windows on it, but so be it.  I would build one but for itx mini pc that looks like it is not fun. 

Thanks for all help + suggestions. 

Why not just add some RAM?

The "Microsoft tax", I know your pain :(

The particular reason I have these older lenovo systems is that I use them as off grid tails systems and they don't have any networking (no wifi, bluetooth) built in.  Not so good for adding RAM or making any modifications.  Pain is done now, money deducted from CC, waiting for the under 20 hour system to arrive :)  Will time the event once it gets here.....

lol, glad I am not the only one !

Depending on where you are in the world since prices vary a lot you can get the 16GB Intel N100 version with a 512GB drive and then buy a 1TB and a m.2 to USB adapter for the 512GB that comes with the unit for 1/2 the price of what you are looking at. Yes it's 16GB vs 32GB but you get to reuse the 512GB m.2 for something.

AND the Intel uses a fraction of the power of the AMD so it's cheaper to run and less noise.

YES it's slower, but once the initial sync is done and it's just running the node & JoinMarket and a few other things it's more then enough.

-Dave

I get the feeling there's an interesting story behind this. Starting with: why Tails, if it's offline?

So my setup with the no wifi linux box is that I do a electrum transaction on one computer, then save it off and sign it on the second computer.  The second computer is an air-gapped not on-line linux that boots tails via a usb.  I use electrum on tails to sign anything.  It is just a way to have air gapped box. 

Thanks for that, I had looked at less expensive options also.

Status update:  the new system rips speed wise.  It got to 100% overnight.  So definitely was hw problem.  I really like the beelink SER5 max, looks well made.  I do not have hour by hour, if I re-index for any reason will post one. 

Some stats are readily written in the debug.log file of Bitcoin Core (time stamps and percentage progress when blocks are digested). If you're lucky, your whole IBD might be still logged.

By default this file will be pruned from time to time (not sure which threshold triggers shrinkage of it), unless you put shrinkdebugfile=0 in your bitcoin.conf. This tells Core to only ever append log entries to the debug.log and never shrink that file.

Glad you're happy with your new hardware and that it works smoothly.

Thanks, yes I see that, can get exact times with likes that show 'progress='...

Yeah, has really been a learning curve.  I initially would not have expected hardware to have such a prominent effect.

Here are the latest times.  I was hoping to finish in under 48 hours, was pleasantly surprised.
Hour 1: 8%
Hour 2: 15%
Hour 3: 28%
Hour 4: 40%
Hour 5: 52%
Hour 6: 62%
Hour 7: 70%
Hour 8: 78%
Hour 9: 87%
Hour 10: 95%
Hour 11: 100%

So with enough RAM, the progress stays more or less linear. Did you increase dbcache settings? I'm not sure if it would still matter: Linux can handle file cache on it's own.

I was going to set it to 12000 but ended up setting it to 8000 for the above run.  Yes looks basically linear :)