<p>bitcoind is often very slow when running over a remote disks (such as on a VPS), especially if that disk is slow.  Check the load of incoming transactions in debug.log, which lock cs_main during processing (which the RPC thread does as well).  If you have the memory, try tmpfs, or increase the bdb cache.</p>

CC BY-SA 3.0
2012-06-26T21:50:29.483Z
If it's a disk problem, the STAT should read "D" (uninterruptible sleep), shouldn't it? However, the filesystem type is `simfs`, so perhaps you're right.
user1513
CC BY-SA 3.0
2012-06-29T01:21:35.793Z
It may not be the RPC thread that is stuck waiting on IO, if any thread holding cs_main (which is most of them when they do IO) is waiting on IO, the RPC thread will have to wait for the other(s) to finish their work.
Matt Corallo
CC BY-SA 3.0
2012-06-26T19:14:59.020Z
2012-06-26T19:14:59.020Z
Matt Corallo
<p>Sometimes it takes bitcoind more than a minute to respond to basic RPC calls such as getbalance (and on average, it takes at least 5 seconds), even though the "STAT" according to the Linux 'ps' program remains "<code>SLl</code>" (Sleeping!). I've confirmed I was looking at the RPC server process and not the client process. How is this even reasonable?</p>

<p>It shouldn't be possible to run large-scale sites like Mt. Gox with those kind of response times. What special considerations need to be taken into account to get performance out of bitcoind? </p>

CC BY-SA 3.0
2012-06-24T17:42:44.693Z
It takes slightly over 0.0s when I run it.  Is your bitcoind trying to sync with the blockchain while you run the RPC commands?
chris@chris:~$ time bitcoind getbalance
5.72535335

real 0m0.020s
user 0m0.000s
sys 0m0.016s
chris@chris:~$
Chris Moore
CC BY-SA 3.0
2012-06-24T20:18:44.937Z
Are you using an encrypted filesystem?  Are you using the most recent release?
Stephen Gornick
CC BY-SA 3.0
2012-06-24T20:28:09.163Z
@Chris Moore `bitcoind getblockcount` matches the block count returned by Block Explorer, so it's fully synced.
user1513
CC BY-SA 3.0
2012-06-24T20:29:49.883Z
@StephenGornick I have v0.6.2-beta. However, the problem has persisted through multiple upgrades. I had the problem back when the current version was 0.3.4. Also, it's not an encrypted filesystem, but it is on an OpenVZ VPS.
user1513
<bitcoind><json-rpc><performance>
Why is bitcoind so slow on VPSs?
user1513
# Why is bitcoind so slow on VPSs?

(Asked by: username_0 on 2012-06-24)

Sometimes it takes bitcoind more than a minute to respond to basic RPC calls such as getbalance (and on average, it takes at least 5 seconds), even though the "STAT" according to the Linux 'ps' program remains "`SLl`" (Sleeping!). I've confirmed I was looking at the RPC server process and not the client process. How is this even reasonable?

It shouldn't be possible to run large-scale sites like Mt. Gox with those kind of response times. What special considerations need to be taken into account to get performance out of bitcoind?

**Tags:** bitcoind, json-rpc, performance

> **Comments:**
> **username_1**: It takes slightly over 0.0s when I run it.  Is your bitcoind trying to sync with the blockchain while you run the RPC commands? username_1@username_1:~$ time bitcoind getbalance 5.72535335  real 0m0.020s user 0m0.000s sys 0m0.016s username_1@username_1:~$  
> **username_2**: Are you using an encrypted filesystem?  Are you using the most recent release?  
> **username_0**: @username_1 `bitcoind getblockcount` matches the block count returned by Block Explorer, so it's fully synced.  
> **username_0**: @username_2 I have v0.6.2-beta. However, the problem has persisted through multiple upgrades. I had the problem back when the current version was 0.3.4. Also, it's not an encrypted filesystem, but it is on an OpenVZ VPS.  

---

## 1 answers

### Answer by username_3 on 2012-06-26. Score: 5 | Accepted answer

bitcoind is often very slow when running over a remote disks (such as on a VPS), especially if that disk is slow. Check the load of incoming transactions in debug.log, which lock cs\_main during processing (which the RPC thread does as well). If you have the memory, try tmpfs, or increase the bdb cache.

> **Comments:**
> **username_0**: If it's a disk problem, the STAT should read "D" (uninterruptible sleep), shouldn't it? However, the filesystem type is `simfs`, so perhaps you're right.  
> **username_3**: It may not be the RPC thread that is stuck waiting on IO, if any thread holding cs_main (which is most of them when they do IO) is waiting on IO, the RPC thread will have to wait for the other(s) to finish their work.  

---

