Extremely slow launch time #2261

(as posted on SE)

bitcoind is extremely slow to start (~5-20 minutes). I'm not talking about keeping up with the blockchain, that would be perfectly fine, I'm talking about an initial phase where it doesn't even respond to requests: any call to it returns "error: couldn't connect to server" (either from command line or from web).

Is it a known issue, is there a workaround?

OSX 10.6.8, bitcoind 0.7.0 (but happened with earlier versions too). Installed on the main and only hard disk, which is not encrypted.

Is that a slow machine? Perhaps you are I/O limited. That should get way better with 0.8. You could also try to lower the -checkblocks to 288, although I'm not sure if this is recommended for 0.7 clients.

I'm not sure but it smells strange to me, the machine is this one: https://en.wikipedia.org/wiki/MacBook#Unibody_aluminum_model

You have a 5400 rpm HDD in it or a SSD? Do you want to say 0.7 is now slower than before (a few weeks ago)?

5400. It has always been slow.

Then this is a non-issue IMHO, as the client is very I/O intensive. As I said this will get much better with the 0.8 release.

Being totally unresponsive for 20 minutes however is very bad. It would be much better if somehow it managed to give some feedback, if only responding "loading" to requests... (of course if it managed to also really answer some requests while loading those data, it would be even better).

@Lohoris please try v0.8.0rc1, and see whether this improves the situation.

@sipa for some reason it started re-downloading the blockchain from 0, so it's going to take a while... I'll let you know : )

Nope, it is still slow as hell :/

i have same issue.

last mac. on macbook pro 8gb memory.

There is nothing specific for us to fix in this issue, except "make it faster on older, slower machines, please." And we already know that, and have a long-term plan to fix it (headers-first simple payment verification mode, graduating into load-full-blocks and full-verification if the machine has enough disk/ram/CPU).

I'm inclined to close this, and recommend that you run a lightweight client like Multibit or Electrum instead of Bitcoin-Qt.

Please bear with me: being slow on slow machines is perfectly fine. What I'd like to see solved is it being unresponsive.

If it has to load stuff at startup and it takes a while, fine. But in the meantime it shouldn't be unresponsive, it should still respond to requests either with the correct answer (if that is already loaded), or with a "please wait, loading" error message.

Obviously if you want to add some logging with timestampt at each "loading phase" (if any), and have me report it, I'd be glad to help.

(btw I'm talking about bitcoind, not the qt client)

also. just keeping bitcoin app in the dock slows down macbook pro for real.

if i keep it running, i unable to watch movies (my memory 4 gb free at the time) movies periodically hungs and continue after several seconds.

@lohoris Are you saying that it still takes 20 minutes to start?

Can you post the debug.log text from on of these startup instances? This doesn't make a lot of sense to me— that just sounds broken even if your machine is very slow.

Do you have a huge wallet.dat file?

188kB.

looris@Palace-of-the-Nine-Moons:/tmp $ ls -lh ~/.bitcoin/
total 14358744
-rw-------   1 looris  staff   5,7M  1 Dic 10:26 addr.dat
-rw-r--r--@  1 looris  staff    56B 28 Nov 17:34 bitcoin.conf
-rw-------   1 looris  staff     4B 11 Feb 15:51 bitcoind.pid
-rw-------   1 looris  staff   2,0G 28 Nov 05:06 blk0001.dat
-rw-------   1 looris  staff   2,0G  5 Dic 11:06 blk0002.dat
-rw-------   1 looris  staff   1,3G 10 Feb 22:23 blk0003.dat
-rw-------   1 looris  staff   1,7G 10 Feb 22:23 blkindex.dat
drwx------  18 looris  staff   612B  1 Dic 11:18 blktree
drwx------  87 looris  staff   2,9K 11 Feb 13:50 blocks
drwx------  87 looris  staff   2,9K 11 Feb 17:42 chainstate
drwx------  11 looris  staff   374B  1 Dic 11:15 coins
drwx------   3 looris  staff   102B 10 Feb 22:47 database
-rw-------   1 looris  staff   714B 30 Mag  2012 db.log
-rw-------   1 looris  staff   613K 11 Feb 17:59 debug.log
-rw-r-----   1 looris  staff    10M 30 Apr  2012 log.0000000001
-rw-------   1 looris  staff   741K 11 Feb 17:58 peers.dat
-rw-------   1 looris  staff   188K 11 Feb 17:58 wallet.dat
-rw-------   1 looris  staff   152K  2 Dic 11:48 wallet.dat.old

looris@Palace-of-the-Nine-Moons:~/.bitcoin $ find . -type d -exec du -sh {} \;
 13G    .
 14M    ./blktree
5,9G    ./blocks
 30M    ./blocks/index
157M    ./chainstate
8,0M    ./coins
10,0M   ./database

I'll post some logs later, thanks.

Looks like it's a bit faster now. Not sure why it didn't improve immediately after upgrading to 0.8, but until this happens again, I'll just close it.

I would also like to confirm this issue and think it would be best if the RPC Server would be the first thing started so it can respond to any client right from the start. It should be on it's own thread so it can respond even if the main thread is choked. Perhaps it could return the value of a global State or something that shows the last instruction being run. "-checkblocks=0 -checklevel=4 -rescan -upgradewallet -dnsseed -listen -checkpoints -gen=0 -printtoconsole -testnet" This can take a bit to complete and the client trying to call out commands doesn't know what state the server is in.