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?

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

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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, 2012 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, 2012 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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