<p>When you're synchronizing from network, you're most likely limited by the rate of fetching blocks. When you're reindexing blocks that are already present on disk, only CPU is the bottleneck.</p>

<p>The algorithm to decide where and when to request blocks is relatively stupid, slow, and easy to confuse. This is why during synchronization from network, you rarely use all bandwidth available. This is being worked on, but it's not a simple problem, if you want to avoid many problematic edge cases. EDIT: bandwidth usage should be a lot better since Bitcoin Core v0.10.</p>

<p>When reindexing block on disk, the reference client will by default use all CPU cores available, to speed up the process. You can put <code>par=1</code> in bitcoin.conf to restrict the validation operation to a single core. As of 0.9 (not yet released), you'll also be able to change this value in the GUI configuration.</p>

CC BY-SA 3.0
2014-02-09T14:41:39.930Z
Thanks Pieter, I only have a peers and dat file in application support? Where is this config file to found - I am assuming I'll know where to add par=1 as there will be a  par value and text edit will do this? cheers
bard
CC BY-SA 3.0
2014-02-09T15:16:57.437Z
It's in the data directory (the same directory that holds peers.dat, wallet.dat, blocks/, chainstate/, ...). If it doesn't exist yet, you can create it using a text editor.
Pieter Wuille
CC BY-SA 4.0
2020-03-30T06:14:54.853Z
Is there a way to make it use less CPU so that it can reindex faster? Progress increase per hour is currently around 0.17% which seems a bit slow (or rather, 3 blocks per second).
Rebroad
CC BY-SA 3.0
2014-02-09T14:30:37.223Z
2015-03-17T21:21:54.730Z
2015-03-17T21:21:54.730Z
Pieter Wuille
<p>My bitcoin qt client v8.5 crashed last week (I had already got full blockchain indexed a long time ago) and I had to force quit it. It's now re-indexing the blockchain but using sometimes up to 427% of Macbook CPU and the fans are on at 6000 revs for hours... It never did this when I first synced up so what is wrong this time round?</p>

<p>Thanks
Bard</p>

<bitcoin-core><cpu>
Reindexing of blockchain using bitcoin qt v8.5 using 427% of Macbook CPU
bard
# Reindexing of blockchain using bitcoin qt v8.5 using 427% of Macbook CPU

(Asked by: username_0 on 2014-02-09)

My bitcoin qt client v8.5 crashed last week (I had already got full blockchain indexed a long time ago) and I had to force quit it. It's now re-indexing the blockchain but using sometimes up to 427% of Macbook CPU and the fans are on at 6000 revs for hours... It never did this when I first synced up so what is wrong this time round?

Thanks
Bard

**Tags:** bitcoin-core, cpu


---

## 1 answers

### Answer by username_1 on 2014-02-09. Score: 2

When you're synchronizing from network, you're most likely limited by the rate of fetching blocks. When you're reindexing blocks that are already present on disk, only CPU is the bottleneck.

The algorithm to decide where and when to request blocks is relatively stupid, slow, and easy to confuse. This is why during synchronization from network, you rarely use all bandwidth available. This is being worked on, but it's not a simple problem, if you want to avoid many problematic edge cases. EDIT: bandwidth usage should be a lot better since Bitcoin Core v0.10.

When reindexing block on disk, the reference client will by default use all CPU cores available, to speed up the process. You can put `par=1` in bitcoin.conf to restrict the validation operation to a single core. As of 0.9 (not yet released), you'll also be able to change this value in the GUI configuration.

> **Comments:**
> **username_0**: Thanks Pieter, I only have a peers and dat file in application support? Where is this config file to found - I am assuming I'll know where to add par=1 as there will be a  par value and text edit will do this? cheers  
> **username_1**: It's in the data directory (the same directory that holds peers.dat, wallet.dat, blocks/, chainstate/, ...). If it doesn't exist yet, you can create it using a text editor.  
> **username_2**: Is there a way to make it use less CPU so that it can reindex faster? Progress increase per hour is currently around 0.17% which seems a bit slow (or rather, 3 blocks per second).  

---

