<p>This is a known problem in the wallet code.</p>

<p>Whenever a new address is retrieved from the key pool, a new key is also generated to replenish the key pool. When this happens, we try to make sure this new key is safely on disk, so we flush the wallet file to disk. Due to probably overly aggressive flushing, this results in large writes to disk in BDB.</p>

CC BY-SA 3.0
2016-06-20T17:53:06.777Z
Would it speed things up if I would set the keypool to 0? Generate the new address directly for the request and skipping the writing to the keypool?
Cremo
CC BY-SA 3.0
2016-06-20T18:50:35.180Z
No, it would still need to generate one. What you can do is set your keypool very large, start bitcoind and let it generate the many keys, and then set the keypool size low again and restart. No new keys will be generated until the keypool is at the low sizr again.
Pieter Wuille
CC BY-SA 3.0
2016-06-22T20:04:50.843Z
Setting the pool large and letting addresses be generated is as fast as requesting them one by one. No time advantage. Setting the pool to 0 however caused some kind of bug? At least bitcoind "lost" ~1.000.000 keys. Judging by the size of the wallet the keys were still in the wallet but the counter bitcoind displayed in the console were off.
Cremo
CC BY-SA 3.0
2016-06-22T21:24:06.193Z
@cremo Setting the pool large will be just as slow, but you can do it way ahead of time.
Pieter Wuille
CC BY-SA 3.0
2016-06-20T14:27:35.710Z
2016-06-20T14:27:35.710Z
Pieter Wuille
<p>It sounds like you are running bitcoind on the same server that is serving up web pages.  I would recommend running bticoind on a separate server altogether, for several reasons:</p>

<ol>
<li>bitcoind does a lot more than simply generate addresses, and therefore takes a lot of resources away from your webserver.</li>
<li>If you are using this instance of bitcoind to actually store coins, it's best to keep it off a public-facing server.  There are ways of securing your wallet, but it's best to simply not expose an attack surface</li>
<li>By running bitcoind on a separate server, you can use it from multiple webservers, making your entire system more scalable</li>
</ol>

<p>Moving bitcoind to a second server will eliminate the resource problem on your webserver, as well as give you an additional layer of security.  These benefits will probably outweigh the cost of the second server.</p>

CC BY-SA 3.0
2016-06-20T17:56:12.197Z
Thanks for the advice but the hole thing runs on my PC and only the addresses will end up on a webserver. I was only using PHP for the RPC calls because it was what I had at hand the fastest.
Cremo
CC BY-SA 3.0
2016-06-20T14:00:03.827Z
2016-06-20T14:00:03.827Z
Jestin
<p>I'm running bitcoind and generate a bunch of bitcoin addresses. I use a PHP script and an Apache2 server to make calls to the RPC API.</p>

<p>bitcoind uses ~ 0.7%-2.2% of the CPU and writes ~3 MB/s on the SSD. 
Apache2 uses ~0.3% of the CPU.</p>

<p>I set -rpcthreads to 8 but that didn't do anything for me.</p>

<p>Where is the bottleneck?
Is there a way to speed the hole process up?</p>

<p>I know that vanitygen can create a lot of addresses but then I would need another step to add them all to a wallet therefor I would prefer using bitcoind. bitcoin-qt is just awful slow at the same task with RPC commands.</p>

<bitcoind><json-rpc>
Bitcoind uses only ~1.5% CPU for RPC command "getnewaddress"
Cremo
# Bitcoind uses only ~1.5% CPU for RPC command "getnewaddress"

(Asked by: username_0 on 2016-06-19)

I'm running bitcoind and generate a bunch of bitcoin addresses. I use a PHP script and an Apache2 server to make calls to the RPC API.

bitcoind uses ~ 0.7%-2.2% of the CPU and writes ~3 MB/s on the SSD.
Apache2 uses ~0.3% of the CPU.

I set -rpcthreads to 8 but that didn't do anything for me.

Where is the bottleneck?
Is there a way to speed the hole process up?

I know that vanitygen can create a lot of addresses but then I would need another step to add them all to a wallet therefor I would prefer using bitcoind. bitcoin-qt is just awful slow at the same task with RPC commands.

**Tags:** bitcoind, json-rpc


---

## 2 answers

### Answer by username_1 on 2016-06-20. Score: 3

This is a known problem in the wallet code.

Whenever a new address is retrieved from the key pool, a new key is also generated to replenish the key pool. When this happens, we try to make sure this new key is safely on disk, so we flush the wallet file to disk. Due to probably overly aggressive flushing, this results in large writes to disk in BDB.

> **Comments:**
> **username_0**: Would it speed things up if I would set the keypool to 0? Generate the new address directly for the request and skipping the writing to the keypool?  
> **username_1**: No, it would still need to generate one. What you can do is set your keypool very large, start bitcoind and let it generate the many keys, and then set the keypool size low again and restart. No new keys will be generated until the keypool is at the low sizr again.  
> **username_0**: Setting the pool large and letting addresses be generated is as fast as requesting them one by one. No time advantage. Setting the pool to 0 however caused some kind of bug? At least bitcoind "lost" ~1.000.000 keys. Judging by the size of the wallet the keys were still in the wallet but the counter bitcoind displayed in the console were off.  
> **username_1**: @username_0 Setting the pool large will be just as slow, but you can do it way ahead of time.  

---

### Answer by username_2 on 2016-06-20. Score: 0

It sounds like you are running bitcoind on the same server that is serving up web pages. I would recommend running bticoind on a separate server altogether, for several reasons:

1. bitcoind does a lot more than simply generate addresses, and therefore takes a lot of resources away from your webserver.
2. If you are using this instance of bitcoind to actually store coins, it's best to keep it off a public-facing server. There are ways of securing your wallet, but it's best to simply not expose an attack surface
3. By running bitcoind on a separate server, you can use it from multiple webservers, making your entire system more scalable

Moving bitcoind to a second server will eliminate the resource problem on your webserver, as well as give you an additional layer of security. These benefits will probably outweigh the cost of the second server.

> **Comments:**
> **username_0**: Thanks for the advice but the hole thing runs on my PC and only the addresses will end up on a webserver. I was only using PHP for the RPC calls because it was what I had at hand the fastest.  

---

