<p>Increasing the database cache should help a lot to reduce disk I/O. For example <code>dbcache=400</code> (100 MB is the default).</p>

CC BY-SA 3.0
2015-12-17T20:11:02.403Z
2015-12-17T20:11:02.403Z
Jannes
<p>I'm trying to make a bitcoin app and would like to use a full node so I purchased a 128gb usb 3.0 drive to store it on. I use an early 2014 macbook air: 1.4 GHz Intel Core i5, 8 GB 1600 MHz DDR3. Is processing being throttled by the usb connection? Drive is formatted as mac os extended journaled.</p>

<p>Using bitcoin core, it is syncing very slowly. After almost 24 hours it says last received block was generated 2 years 3 weeks ago. The sync bar is about 1/8 of the way done. Any thoughts or recommendations would be helpful.</p>

CC BY-SA 3.0
2015-12-17T01:38:47.873Z
I'd expect disk latency / seek time to be more of a bottleneck than throughput.  Verifying the blockchain means lots of random reads and writes to find and update transactions in the database.  Something I might try is to make symlinks so that `blocks/index/` and `chainstate/` are on a ramdisk, and then copy them back to the disk after syncing is complete.
Nate Eldredge
CC BY-SA 3.0
2015-12-17T01:40:33.073Z
Another option is simply that you are limited in downloading the blocks by network bandwidth, or by the responsiveness of your peers.  If you look at top or the OSX equivalent, how much time is spent in running and/or iowait?
Nate Eldredge
CC BY-SA 3.0
2015-12-17T13:09:09.700Z
It might help to increase your dbcache option. For example `dbcache=400` (I think 100 MB is the default)
Jannes
CC BY-SA 3.0
2015-12-17T17:50:28.700Z
@jannes, This is what ended up working. I set it to 5000 and it looks like it will finish in a day or two thanks.
joemillervi
CC BY-SA 3.0
2015-12-17T20:10:47.517Z
I'll put it in an answer then instead of a comment. Please accept.  Also: you might want to turn it back down a bit after the initial sync has finished. 5GB sounds like a bit overkill.
Jannes
CC BY-SA 3.0
2015-12-18T01:47:30.543Z
@Jannes Will do currently it is using about 600MB
joemillervi
<blockchain><bitcoind><bitcoin-core>
Syncing node to usb 3.0 drive taking ages
joemillervi
# Syncing node to usb 3.0 drive taking ages

(Asked by: username_0 on 2015-12-17)

I'm trying to make a bitcoin app and would like to use a full node so I purchased a 128gb usb 3.0 drive to store it on. I use an early 2014 macbook air: 1.4 GHz Intel Core i5, 8 GB 1600 MHz DDR3. Is processing being throttled by the usb connection? Drive is formatted as mac os extended journaled.

Using bitcoin core, it is syncing very slowly. After almost 24 hours it says last received block was generated 2 years 3 weeks ago. The sync bar is about 1/8 of the way done. Any thoughts or recommendations would be helpful.

**Tags:** blockchain, bitcoind, bitcoin-core

> **Comments:**
> **username_1**: I'd expect disk latency / seek time to be more of a bottleneck than throughput.  Verifying the blockchain means lots of random reads and writes to find and update transactions in the database.  Something I might try is to make symlinks so that `blocks/index/` and `chainstate/` are on a ramdisk, and then copy them back to the disk after syncing is complete.  
> **username_1**: Another option is simply that you are limited in downloading the blocks by network bandwidth, or by the responsiveness of your peers.  If you look at top or the OSX equivalent, how much time is spent in running and/or iowait?  
> **username_2**: It might help to increase your dbcache option. For example `dbcache=400` (I think 100 MB is the default)  
> **username_0**: @username_2, This is what ended up working. I set it to 5000 and it looks like it will finish in a day or two thanks.  
> **username_2**: I'll put it in an answer then instead of a comment. Please accept.  Also: you might want to turn it back down a bit after the initial sync has finished. 5GB sounds like a bit overkill.  
> **username_0**: @username_2 Will do currently it is using about 600MB  

---

## 1 answers

### Answer by username_2 on 2015-12-17. Score: 3 | Accepted answer

Increasing the database cache should help a lot to reduce disk I/O. For example `dbcache=400` (100 MB is the default).


---

