<p>The behavior I noticed from a reindex on my node was that it ended up reloading the entire blockchain from the Internet. This is consistent with what the Bitcoin Meister Pieter Wuille indicated. Will have to remember the dbcache trick... </p>

CC BY-SA 3.0
2015-07-07T03:20:34.013Z
2015-07-07T03:20:34.013Z
skaht
<p>I know this is an older question, but I've found it now, so I think it can be good for others who will find this thread.</p>

<p>You should download the latest version of bitcoin QT (0.15.1 as of writing this)
which has some performance tweaks and it reindex on disk about 10 times faster than the 0.12 which i had before.</p>

<p>saying that, you could also download blockchain from torrents. Here is the official link to torrent
<a href="https://bitcoin.org/bin/block-chain/" rel="nofollow noreferrer">https://bitcoin.org/bin/block-chain/</a></p>

<p>After downloading it, you should call</p>

<pre><code>bitcoin-qt.exe -datadir=&lt;path to Bitcoin dir&gt; -rescan
</code></pre>

<p>And the speed will come to you. ;)</p>

CC BY-SA 3.0
2018-01-13T13:44:23.600Z
Downloading through torrents is actually not faster than letting bitcoin-qt do the downloading. Used to be several years ago, but these days bitcoin itself does a better job than bittorrent and can then do validation in parallel to the downloading. The link you provided points to a 2014 torrent file. That shows how outdated this trick is.
Jannes
CC BY-SA 3.0
2017-11-27T15:02:42.430Z
2017-11-27T15:02:42.430Z
Jiří Herník
<p>Increasing dbcache is probably the most important thing you can do:</p>
<pre><code>-dbcache=1000
</code></pre>
<p>Another thing to do is to disable all console output:</p>
<pre><code>-printtoconsole=0
</code></pre>
<p>Apart from that, if your disk is the bottleneck, you can move parts of the blockchain data to a faster disk. The majority of the blockchain (the blocks themselves) can stay on a slow HDD, and you can move <code>chainstate</code> and <code>index</code> (inside <code>blocks</code>) folders to an SSD by creating symbolic links.</p>

CC BY-SA 4.0
2020-07-19T14:58:05.970Z
2020-07-19T14:58:05.970Z
GChuf
<blockquote>
  <p>reindex doesn't also re-validate blocks, does it?</p>
</blockquote>

<p>It does, but signature verification (the slowest bit) is skipped on most of the early blockchain. The command attempts to sync with the network by reusing as many blocks as possible that are already written to the disk, which may very well include damaged or partially written ones. </p>

<blockquote>
  <p>Any experience with speeding this up</p>
</blockquote>

<p>Increasing the <code>dbcache</code> will speed up reindexing, putting it at 2G (<code>dbcache=2048</code>) would not be an unreasonable choice given you have the memory. This is about all you can do, until it gets to the point where you are validating signatures a reindex is heavily single threaded. </p>

CC BY-SA 3.0
2015-07-05T20:20:25.273Z
How is it determined which signatures are verified -- after the last checkpoint? Is there a technical reason this is necessary, as opposed to, say, just verifying block hashes and PoW until the last couple dozen/hundred?
jwelsh
CC BY-SA 3.0
2015-07-05T20:32:15.460Z
All signatures after the last checkpoint. Optimally all signatures would always be verified but the sync time would just be extreme, not doing it at all would risk decentralization. It's a crutch for the fact that ECDSA is slow and there's a lot of transactions in the Bitcoin blockchain to verify.
Claris
CC BY-SA 3.0
2015-07-05T22:45:10.523Z
Put more simply: reindez does exactly the same as redownloading the chain from scratch, except it reuses the blocks on disk you already have.
Pieter Wuille
CC BY-SA 3.0
2015-07-06T02:00:32.200Z
Ahh... and that explains why the first 295k blocks go so much faster, in both initial sync and reindex.
jwelsh
CC BY-SA 3.0
2016-06-05T00:42:55.040Z
@PieterWuille Does this mean a bigger `dbcache` will not speed up?
Fish Monitor
CC BY-SA 3.0
2016-06-05T07:16:17.563Z
@fossilet Sure it does. Read the answer above.
Pieter Wuille
CC BY-SA 3.0
2015-07-05T20:08:36.863Z
2015-07-06T08:50:24.037Z
2015-07-06T08:50:24.037Z
Claris
<p>I just reindexed a node that was already synced (in order to enable txindex); it took around 9 hours. It's on a pretty good system: 16G RAM, i7 with 4 physical cores. Storage is a weak point, with LUKS on software RAID0 on spinning disks. dbcache is at the default 100M, though I'm running 0.11 so I gather this ends up smaller than the previous default due to more accurate accounting. By extrapolation from testing a subset, a sequential read of the full ~38G of blk files should take ~4 minutes.</p>

<p>I understand reindex includes rebuilding the chainstate db, so I'm guessing that's the bottleneck. Questions: 1) reindex doesn't also re-validate blocks, does it? 2) Any experience with speeding this up -- perhaps putting chainstate on a tmpfs and copying to permanent storage once complete?</p>

<p>Followup: by increasing dbcache as suggested, and adding a recent custom checkpoint to the code, I got another reindex done in about 3 hours.</p>

CC BY-SA 3.0
2017-01-06T20:30:42.427Z
I like the "custom checkpoint" idea.  It suggests that a feature could be added to allow any user to make one from the GUI, so, for example, if you want your client to keep running but you know you're doing something that might crash your machine, you could checkpoint right here and vastly speed up your recovery - or "replace last checkpoint with current state".  Have you made such a suggestion anywhere?
Dave Scotese
<bitcoind><database><performance>
Possible to speed up reindex?
jwelsh
# Possible to speed up reindex?

(Asked by: username_0 on 2015-07-05)

I just reindexed a node that was already synced (in order to enable txindex); it took around 9 hours. It's on a pretty good system: 16G RAM, i7 with 4 physical cores. Storage is a weak point, with LUKS on software RAID0 on spinning disks. dbcache is at the default 100M, though I'm running 0.11 so I gather this ends up smaller than the previous default due to more accurate accounting. By extrapolation from testing a subset, a sequential read of the full ~38G of blk files should take ~4 minutes.

I understand reindex includes rebuilding the chainstate db, so I'm guessing that's the bottleneck. Questions: 1) reindex doesn't also re-validate blocks, does it? 2) Any experience with speeding this up -- perhaps putting chainstate on a tmpfs and copying to permanent storage once complete?

Followup: by increasing dbcache as suggested, and adding a recent custom checkpoint to the code, I got another reindex done in about 3 hours.

**Tags:** bitcoind, database, performance

> **Comments:**
> **username_1**: I like the "custom checkpoint" idea.  It suggests that a feature could be added to allow any user to make one from the GUI, so, for example, if you want your client to keep running but you know you're doing something that might crash your machine, you could checkpoint right here and vastly speed up your recovery - or "replace last checkpoint with current state".  Have you made such a suggestion anywhere?  

---

## 4 answers

### Answer by username_6 on 2015-07-05. Score: 11 | Accepted answer

> reindex doesn't also re-validate blocks, does it?

It does, but signature verification (the slowest bit) is skipped on most of the early blockchain. The command attempts to sync with the network by reusing as many blocks as possible that are already written to the disk, which may very well include damaged or partially written ones.

> Any experience with speeding this up

Increasing the `dbcache` will speed up reindexing, putting it at 2G (`dbcache=2048`) would not be an unreasonable choice given you have the memory. This is about all you can do, until it gets to the point where you are validating signatures a reindex is heavily single threaded.

> **Comments:**
> **username_0**: How is it determined which signatures are verified -- after the last checkpoint? Is there a technical reason this is necessary, as opposed to, say, just verifying block hashes and PoW until the last couple dozen/hundred?  
> **username_6**: All signatures after the last checkpoint. Optimally all signatures would always be verified but the sync time would just be extreme, not doing it at all would risk decentralization. It's a crutch for the fact that ECDSA is slow and there's a lot of transactions in the Bitcoin blockchain to verify.  
> **username_7**: Put more simply: reindez does exactly the same as redownloading the chain from scratch, except it reuses the blocks on disk you already have.  
> **username_0**: Ahh... and that explains why the first 295k blocks go so much faster, in both initial sync and reindex.  
> **username_8**: @username_7 Does this mean a bigger `dbcache` will not speed up?  
> **username_7**: @fossilet Sure it does. Read the answer above.  

---

### Answer by username_2 on 2015-07-07. Score: 1

The behavior I noticed from a reindex on my node was that it ended up reloading the entire blockchain from the Internet. This is consistent with what the Bitcoin Meister username_7 username_7 indicated. Will have to remember the dbcache trick...


---

### Answer by username_3 on 2017-11-27. Score: 0

I know this is an older question, but I've found it now, so I think it can be good for others who will find this thread.

You should download the latest version of bitcoin QT (0.15.1 as of writing this)
which has some performance tweaks and it reindex on disk about 10 times faster than the 0.12 which i had before.

saying that, you could also download blockchain from torrents. Here is the official link to torrent
<https://bitcoin.org/bin/block-chain/>

After downloading it, you should call

```
bitcoin-qt.exe -datadir=<path to Bitcoin dir> -rescan

```

And the speed will come to you. ;)

> **Comments:**
> **username_4**: Downloading through torrents is actually not faster than letting bitcoin-qt do the downloading. Used to be several years ago, but these days bitcoin itself does a better job than bittorrent and can then do validation in parallel to the downloading. The link you provided points to a 2014 torrent file. That shows how outdated this trick is.  

---

### Answer by username_5 on 2020-07-19. Score: 0

Increasing dbcache is probably the most important thing you can do:

```
-dbcache=1000

```

Another thing to do is to disable all console output:

```
-printtoconsole=0

```

Apart from that, if your disk is the bottleneck, you can move parts of the blockchain data to a faster disk. The majority of the blockchain (the blocks themselves) can stay on a slow HDD, and you can move `chainstate` and `index` (inside `blocks`) folders to an SSD by creating symbolic links.


---

