Why is bitcoind so slow on VPSs?

5

3

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?

user1513

Posted 2012-06-24T06:38:41.817

Reputation: 101

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 – 2012-06-24T17:42:44.693

Are you using an encrypted filesystem? Are you using the most recent release? – Stephen Gornick – 2012-06-24T20:18:44.937

@Chris Moore bitcoind getblockcount matches the block count returned by Block Explorer, so it's fully synced. – user1513 – 2012-06-24T20:28:09.163

@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 – 2012-06-24T20:29:49.883

If you are unable to resolve this you could try http://blockchain.info/json_rpc_api as an alternative.

– Ben Reeves – 2012-06-27T12:44:14.640

Answers

5

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.

Matt Corallo

Posted 2012-06-24T06:38:41.817

Reputation: 324

1If 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 – 2012-06-26T21:50:29.483

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 – 2012-06-29T01:21:35.793

Asked: 2012-06-24T06:38:41.817

Viewed: 1 290 times

Active: 2012-06-26T21:47:01.890