bitcoin core qt only use 1 core on cpu

[carlo_0000]

hello i have a 8 core cpu
but bitcoin core use only 1 thread, cpu load is 12%  and so it s very slow

can't is work in multi thread ?

[Rath_]

hello i have a 8 core cpu
but bitcoin core use only 1 thread, cpu load is 12%  and so it s very slow

What CPU do you have? There may be a few things about your setup that can be a bottleneck. Using an SSD instead of a HDD makes a huge difference. Also, disabling any kind of antivirus software helps a lot. After I have disabled a real time protection in Windows Defender, the 'progress increase per hour' immediately rose from 0.10% to 12% and the CPU usage peaked at 30% instead of 14%.

FYI, I have an Intel i5-6600k and use Corsair's 1TB NVMe drive.

[carlo_0000]

its  not a hdd problem

hdd usage is 10-20%

the cpu is fx8300  and only 1 core is working

[pereira4]

its  not a hdd problem

hdd usage is 10-20%

the cpu is fx8300  and only 1 core is working

Most likely you are just connected to a slow peer, so the client isn't making that much of an use of the CPU. Try manually connecting to some good nodes and see if things speed up:

https://bitnodes.earn.com/nodes/leaderboard/

Also if you have enough ram you can try raising =dbcache

As far as threads goes there's =par but I wouldn't touch that, I doubt there's anything wrong with your CPU or the software, probably just slow action on the peers side.

And poster above suggested that you use an SSD, and I assume you are using an HDD which is a massive bottleneck on the i/o.

[NeuroticFish]

One common mistake is connecting though a (slow) WiFi.
If possible, use a wired connection while synchronizing, especially if it's the first sync or one after a long period of being offline.

[Rath_]

the cpu is fx8300  and only 1 core is working

Your CPU performance seems to about the same as mine, so it shouldn't be a problem. How much RAM do you have?

its  not a hdd problem

hdd usage is 10-20%

Don't trust Windows Task Manager. Bitcoin Core will never use 100% of your HDD. The initial sync takes less time on SSDs since they have lower access times. I would recommend you getting a small SSD for the OS, programs and the chainstate.

[carlo_0000]

thanks for help but

it has nothing to do with wifi or slow peers

here i m talking about the start of bitcoin qt when it scan the blockchain it doesn't need any connection for that
(i have a lot of old wallet.dat and need to open them all to see if there is btc in it, so each time it need to do a hole scan)

i have 16gb of ram, and here it only use 200mb

and won't do anything if it s a hdd or an ssd

i m telling you it s looked on 1 cpu core only

i m not noob i can see that the hdd is not in use

and how can you say , don't trust windows about hdd usage, any proof for that that is show wrong data?

anyway i m telling you hard drive is not in use, the led is blinking to much
and if i open other program or copy a file it s fast enough, it would be pretty slow if the driver was heavily used by bitcoin


and other clue is the cpu 1 core is 100%  the other just idle and don'st matter what it keep like that

so if it was limited by the hdd, then if i open an other program or copy a file , cpu would drop because of slower access to the hdd and it s not

all point to the cpu  program is using only 1 core


for me it s look like the program cannot do multi thread


ok so i did an other test
i closed digibyte wallet and open it again
cpu for bitcoin qt drop a bit around  10% (was 12%)
hdd goes 100% usage in first minute and drop to 75% later   dgb wallet use also 12% cpu (1 fullcore) using 2.5gb of memory
and wallet was started in less than 3 minutes, did not slow down because of bitcoin qt

and looks like didibyte wallet is also single core program

i will try later on my ryzen   but i need to make some space on the hdd  to see if it also use only 1 core
not possible to test on a ssd because my biggest ssd is 120g  and  it need at lease 250g but pretty sure it s not a hdd problem

[Rath_]

and other clue is the cpu 1 core is 100%  the other just idle and don'st matter what it keep like that
hdd goes 100% usage in first minute and drop to 75% later   dgb wallet use also 12% cpu (1 fullcore) using 2.5gb of memory

There seems to be a problem with this CPU in particular. I found an old thread in which OP stated that he had the same CPU as you and experienced some performance issues. What motherboard do you have? Can you check if you have the latest version of BIOS? There might be something wrong with your BIOS settings.

[dothebeats]

Why do you want to run Core in more cores than 1 though? That wouldn't make things faster in any way for the said software. If you want Core's performance to improve, you need to improve on things where it is most focused on which is storage for parsing blocks faster and reading/writing data and of course, connectivity for grabbing the necessary information on the blockchain. By default, Bitcoin Core already optimizes the configuration depending on your system's specifications.

Have a read on this exchange for further information.

[nc50lc]

here i m talking about the start of bitcoin qt when it scan the blockchain it doesn't need any connection for that
(i have a lot of old wallet.dat and need to open them all to see if there is btc in it, so each time it need to do a hole scan)

i have 16gb of ram, and here it only use 200mb

Next time, take the time to include all these info right from the start.

Have you already tried increasing the dbcache to half of your RAM? like 8192MB.
The cache isn't limited for verification but also start-up: Step7 Cache Sizes.
Note: the min-max value wasn't the same for the latest version.

If you have GUI, open "Options->Main Tab->Size of database cache"; if not, add dbcache=8192 to your bitcoin.conf file.

and other clue is the cpu 1 core is 100%  the other just idle and don'st matter what it keep like that

Hmm, when the other cores aren't needed, it wont be used.
Or it could be a problem with your system, do you have any other CPU-intensive applications for testing?

[NeuroticFish]

(i have a lot of old wallet.dat and need to open them all to see if there is btc in it, so each time it need to do a hole scan)

Sorry, but I would clearly not use Bitcoin QT for such a task.

First of all, I'd make a list of (receiving) addresses (yes, no need for priv keys only for balance). Since you wrote it's old wallets, I guess there no new receiving addresses where you receive coins.

Then I could do:

Option 1: Add all those addresses in one step into Electrum as watch wallets. Whenever you want to check, simply open Electrum and check them. If you want to spend, you'll see which address has the funds and then open that one wallet.dat in BitcoinQT.

Option 2: If the list of addresses is not too big, you can add them to Blockchain.com wallet (yes, watch wallets) and set it to notify you by e-mail when you receive funds. Much less hassle. (I don't know if it works for more addresses, I used it for one only, but I don't see why it would not work).

[carlo_0000]

(i have a lot of old wallet.dat and need to open them all to see if there is btc in it, so each time it need to do a hole scan)

Sorry, but I would clearly not use Bitcoin QT for such a task.

i m confused i never tested  electrum
can i open there all the wallet.dat ?
or you talking about  to know the receiving address, because if i knew the receiving address i just use the explorer then to check balance

i think i just will keep opening them in bitcoinqt  if i open 1 a day i will be finish in 40 days    it s ok nothing urgent

nc50lc

i will try increasing the dbcache
my bitcoin.conf is empty
thanks for the info



maybe it doesn't need more than 1 core but doens't explain why hdd is not full used then

i have bitcoin core installed on an older computer  coreduo 3.3ghz   and it only use 40% cpu  but here hdd hit 100%
edit: hum actually that was only first minute
now it  does the same thing  use 1 full core only    and hdd goes 8-10%  

i notice this

Code:

Thread Startup
The code uses boost::thread_groups to manage the various threads.

It should be noted that although Bitcoin Core is a multi-threaded program, "the reference Satoshi client is largely single-threaded.

looks like it s normal just stuck to 1 core

[ranochigo]

i m confused i never tested  electrum
can i open there all the wallet.dat ?
or you talking about  to know the receiving address, because if i knew the receiving address i just use the explorer then to check balance

You can't import wallet.dat into Electrum. You would have to extract all the private keys and import them into the client. Its a tedious process and many things could go wrong.

i think i just will keep opening them in bitcoinqt  if i open 1 a day i will be finish in 40 days    it s ok nothing urgent

Rescanning your wallet.dat shouldn't take that much time. The only thing that is time-consuming should be your initial block chain synchronisation and rescanning is basically just a matter of searching through the UTXO database which shouldn't take long.

[LoyceV]

(i have a lot of old wallet.dat and need to open them all to see if there is btc in it, so each time it need to do a hole scan)

As far as I know, scanning your existing blockchain isn't a very CPU-intensive task. In my experience (on HDD), it's mainly limited by disk speed.

Have you tried loading multiple wallets at once in the latest version of Bitcoin Core? I haven't tested it myself, but I can imagine it saves a lot of time if you're checking many wallets.

Why do you want to run Core in more cores than 1 though?

Unless your internet or disk speed is the limitation, Bitcoin Core can use multiple CPU cores when verifying blocks. Mine typically consumes all the CPU it can gets until it's fully synced.

[Jet Cash]

A personal observation on some of the above comments. I use a mix of computers over public WiFi, and the two things that seem to make the greatest difference for me are the number and quality of the peers that connect with me, and the use of an SSD rather than an HDD.

[pereira4]

for me it s look like the program cannot do multi thread


ok so i did an other test
i closed digibyte wallet and open it again
cpu for bitcoin qt drop a bit around  10% (was 12%)
hdd goes 100% usage in first minute and drop to 75% later   dgb wallet use also 12% cpu (1 fullcore) using 2.5gb of memory
and wallet was started in less than 3 minutes, did not slow down because of bitcoin qt

and looks like didibyte wallet is also single core program

i will try later on my ryzen   but i need to make some space on the hdd  to see if it also use only 1 core
not possible to test on a ssd because my biggest ssd is 120g  and  it need at lease 250g but pretty sure it s not a hdd problem

Digibyte is a fork of Bitcoin Core's client, basically whatever in fashion Bitcoin Core is interacting with your hardware Digibyte will do the same.

Multithreading is not used for validating the blockchain, unfortunately, there's no benefit from it right now.

[Desten]

I confirm that Bitcoin Core uses only one thread.

Few setups, one for example:

Code:

Bitcoin Core 24.0.1, 24.1rc1, Windows
128Gb RAM, SSD 5-7/5-7 Gb/s >1Tb, 32 cores Ryzen, 100Mbit/1Gbit ethernet.
dbcache set to 64/48/32/16/8/2 Gb
par set to 30/24/16/8/0
txindex=0
maxorphantx=4096/1024/256/0
maxmempool=2048/1024/256
blockreconstructionextratxn set at 16M/1M/256k/4096 and 512 (not M/k of course, 16777216 etc)
txindex=0
maxreceivebuffer set to 16384/4096/1024
maxsendbuffer set to 8192/1024/512
checkblocks=3
checklevel=1
checkmempool set to 10000/100/0
checkpoints set to 0/1
maxsigcachesize set to 2048/512/32
dblogsize set to 256/96/64

Wallet started at first time. No data, no blocks etc.
First blocks was downloaded very fast, there is no questions to network download speed/disk activity etc. Then after downloading and writing some blk*.dat Core starts to check blocks, hashes etc - rev*.dat files created. Higher the blocks lesser the speed of calculating (repeating that no questions to network/disk).
At ~98% of completing something went wrong and wallet must be closed gracefully - finished normally, debuglog contains lines that all finished smoothly. (Any situation can happen - no electricity, crash, out of space - it's not important now)
Restarted bitcoin-qt and... it started to "sync headers" from ZERO. With a speed near 0.02%/h. WTF?
Restarted again - the same situation.
Ok, let's try -reindex. But before that copy some blk* and rev* to other SSD.
bitcoin-qt -reindex -> it is opened and started to reindex from beginning. Watching for blk* and rev* files - blk's are not touched with write activity, only load (extremely fast) then Core started to recalc something and rewrite rev* files. Only one core of CPU is used! After waiting for a long time just compared new rev's to backed up - they are identical, so it was no need in reindexing/rewriting them... but... Ok.
Something went wrong again near the end (not important now what and why).
Restarted bitcoin-qt and situation repeated - 0.02%/h.
-reindex again and all the same.

Code:

Benchmarks:
filesize: blk03200.dat .. blk03249.dat - 6'681'054'357 bytes
download speed: 737 s at 100 Mbit (8.64 Mb/s) and 90 s at 1Gbit (70.81 Mb/s)
read from disk speed: 0.91-0.93 s (6.9 Gb/s)

filesize: rev03200.dat .. rev03249.dat - 966'121'582 bytes
(re)indexing by Bitcoin Core (only one core of 32 is used, no matter what "par" is): 617-628 s (1.46 Mb/s)

So the big question(s) is:
1) why (re)indexing is so slow and uses only ONE core of CPU and not all of them or is in "pre" option (if there is importance that one block must be checked after previous block then there is a simple solution - check all sequential blocks at once in different threads and then if all is ok with their chain calc next blocks but now it supposed to be just one block at a time!)
2) why wallet is not just compare calculations to what was written to rev's previously not to strain and wear out disks, especially SSD's? (blk's FYI can be placed to mid-range HDD with 150-120Mb/s speed without any losses just because blk's are read sequentially)
3) when someone uses -resync then... bitcoin core downloads blocks from the net from scratch?.. why?.. it is soooo wrong I think. Much much better would be read blocks from disk, calculate hashes for them or their parts, compare hashes to other nodes and only when the filesize and a hashes are not identical then redownload. This moment I think is hard to code because (as I understand) blockfiles can differ from machine to machine because of different map of blocks inside it, but why? It can't be organised the same way in all network? If this can be done then all network can breathe much easier when someone resyncs because only hashes of blockfiles can be transferred if blockfiles are okay.

PS: I've found I can use assumevalid=blockhash to skip days of work, it's ok but not the case of the problem (previously if everytime something goes wrong I have ~1 try per day).