5

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?

  • 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 Jun 24 '12 at 17:42
  • Are you using an encrypted filesystem? Are you using the most recent release? – Stephen Gornick Jun 24 '12 at 20:18
  • @Chris Moore bitcoind getblockcount matches the block count returned by Block Explorer, so it's fully synced. – user1513 Jun 24 '12 at 20:28
  • @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 Jun 24 '12 at 20:29
  • If you are unable to resolve this you could try blockchain.info/json_rpc_api as an alternative. – Ben Reeves Jun 27 '12 at 12:44
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.

  • 1
    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 Jun 26 '12 at 21:50
  • 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 Jun 29 '12 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.