<blockquote>
  <p>Or is is possible to allocate multiple cores(not threads) to JSON rpc</p>
</blockquote>

<p>No. The problem is not to do with thread or core allocation. Rather Bitcoin Core makes use of locks to keep the chain state consistent when multiple threads may access it. In this case, you will need to access the chain state to get transactions so multiple <code>getrawtransaction</code> calls cannot really be run in parallel (locks aren't held for the entire call, but they are held for the parts that matter). So adding more cores or threads won't help at all.</p>

<p>The only thing that does help is to use the <code>blockhash</code> parameter. Without it, <code>getrawtransaction</code> will wait until Bitcoin Core isn't in the middle of processing multiple blocks, and the check and wait for this takes some time. However if you specify the <code>blockhash</code>, it will know immediately which block to look in and quickly look it up, no blocking or waiting for blocks to be processed. So this will be faster than without.</p>

<p>Otherwise there's nothing else that you can do.</p>

CC BY-SA 4.0
2019-07-16T11:33:01.433Z
Hi Andrew, thank you for your insight. So even if the block is from 2014, there still needs to be a read lock to maintain chain state?
Roderick Obrist
CC BY-SA 4.0
2019-07-16T02:04:24.400Z
2019-07-16T02:04:24.400Z
Ava Chow
<p>At this point, your best bet is probably launching a bunch of 1 core pods on Kubernetes with copies of the chain lol</p>

CC BY-SA 4.0
2024-08-12T18:50:02.573Z
2024-08-12T18:50:02.573Z
Enclo Creations
<p>I'm trying to scale getrawtransaction calls from bitcoind, without manually parsing the .dat files.</p>

<p>I've tried:</p>

<ul>
<li>rpcworkqueue=512 (no difference)</li>
<li>rpcthreads=128 (no difference)</li>
<li>par=8 (no difference)</li>
<li>passing the blockhash with every call to avoid searching the txindex (big difference)</li>
<li>using JSON rpc batching (big difference)</li>
<li>having two separate instances on the same pc and rotating requests (double speed, but costs 200GB)</li>
</ul>

<p>It seems that a bitcoind will only ever devote 1 core of the cpu to JSON RPC, so when it gets to 100% the only way to scale is with another instance. Unfortunately my server has 24 cores at 2.1GHZ.</p>

<p>Does anyone know if it's possible to have two instances of bitcoind running in the same folder. I.E. one instance is connected to the network and the other instance is running in a read only mode.</p>

<p>Or is is possible to allocate multiple cores(not threads) to JSON rpc</p>

<p>Any help is appreciated, thank you.</p>

<bitcoind><json-rpc>
How to scale JSON-RPC
Roderick Obrist
# How to scale JSON-RPC

(Asked by: username_0 on 2019-07-15)

I'm trying to scale getrawtransaction calls from bitcoind, without manually parsing the .dat files.

I've tried:

* rpcworkqueue=512 (no difference)
* rpcthreads=128 (no difference)
* par=8 (no difference)
* passing the blockhash with every call to avoid searching the txindex (big difference)
* using JSON rpc batching (big difference)
* having two separate instances on the same pc and rotating requests (double speed, but costs 200GB)

It seems that a bitcoind will only ever devote 1 core of the cpu to JSON RPC, so when it gets to 100% the only way to scale is with another instance. Unfortunately my server has 24 cores at 2.1GHZ.

Does anyone know if it's possible to have two instances of bitcoind running in the same folder. I.E. one instance is connected to the network and the other instance is running in a read only mode.

Or is is possible to allocate multiple cores(not threads) to JSON rpc

Any help is appreciated, thank you.

**Tags:** bitcoind, json-rpc


---

## 2 answers

### Answer by username_1 on 2019-07-16. Score: 3

> Or is is possible to allocate multiple cores(not threads) to JSON rpc

No. The problem is not to do with thread or core allocation. Rather Bitcoin Core makes use of locks to keep the chain state consistent when multiple threads may access it. In this case, you will need to access the chain state to get transactions so multiple `getrawtransaction` calls cannot really be run in parallel (locks aren't held for the entire call, but they are held for the parts that matter). So adding more cores or threads won't help at all.

The only thing that does help is to use the `blockhash` parameter. Without it, `getrawtransaction` will wait until Bitcoin Core isn't in the middle of processing multiple blocks, and the check and wait for this takes some time. However if you specify the `blockhash`, it will know immediately which block to look in and quickly look it up, no blocking or waiting for blocks to be processed. So this will be faster than without.

Otherwise there's nothing else that you can do.

> **Comments:**
> **username_0**: Hi Andrew, thank you for your insight. So even if the block is from 2014, there still needs to be a read lock to maintain chain state?  

---

### Answer by username_2 on 2024-08-12. Score: 0

At this point, your best bet is probably launching a bunch of 1 core pods on Kubernetes with copies of the chain lol


---

