0.11.0-win64 unresponsive (“Focus + Enter” workaround) #6784

1. 
   vayvanne commented at 9:19 pm on October 8, 2015: none

   Hi, just noticed that my 0.11.0-win64 full node running on laptop becomes unresponsive, drops connections (both p2p and rpc), hogs memory (may take up to 4GB out of total 6). It restores normal operation after a while but then again becomes unresponsive. I restarted bitcoind and even spent a few days to reindex DB, with no luck. Does this mean that my laptops 5400 RPM HDD is not fast enough to run full node? Or does it mean that it is a bug? bitcoin.conf is almost empty. Only rpc username, password and non-standard network port number there. Thanks for any clues. vay
2. 
   Diapolo commented at 7:26 am on October 9, 2015: none

   IMHO a 5400 RPM HDD is not ideal to be honest… it was smoother with versions before 0.11?
3. 
   vayvanne commented at 8:30 pm on October 9, 2015: none

   It was fine until few days ago. I notice that hangup happens when bitcoind begin to read chainstate .ldb files on about 500Kb/s speed. That takes a long, processor is not loaded much, no response to p2p connections, rpc connects timing out… Another scenario is when bitcoind starts to write to .ldb files and becomes unresposive until finished. In that case it fully loads one of processor cores and memory use drops at the end of this process. I am solo mining using cgminer 4.9.2, so this may be also involved though no changes if I switch to the backup pool temporarily. Will set DB cache size relatively small just for the case if the reason is that my laptop processor core is not fast enough to deal with huge buffered data timely. Thanks for response.
4. 
   sipa commented at 8:35 pm on October 9, 2015: member

   I expect that the problems now are from having a huge mempool. You can increase the minimum relay fee, or help test the mempool limiting patches (whicb likely will go into 0.12).
5. 
   vayvanne commented at 8:57 pm on October 9, 2015: none

   @sipa getmempoolinfo gives 271MB on my laptop so far and increasing. I see a lot of “inputs already spent” and “free transaction rejected by rate limiter” in the debug.log. on the other server machine it is more than 1GB. really seems as a DDoS to network.
6. laanwj added the label Windows on Oct 13, 2015
7. 
   laanwj commented at 7:45 am on October 20, 2015: member

   Do you still get this with 0.11.1?
8. 
   vayvanne commented at 11:16 am on October 20, 2015: none

   No. Thank you.
9. 
   vayvanne commented at 1:28 pm on October 21, 2015: none

   I am recalling my last answer. I did run with default relay fee and it freezes just like the 0.11.0. Restarting now with -minrelaytxfee=0.0001 will report back after a while.
10. 
    vayvanne commented at 9:52 pm on October 24, 2015: none

    With -minrelaytxfee=0.0001 flight is normal so far. -getmempoolinfo gives: { “size” : 2130, “bytes” : 33420250 }
11. 
    vayvanne commented at 10:25 am on November 4, 2015: none

    Increased -minrelaytxfee to 0.0003, as the issue persisted (with 0.0001).
12. 
    vayvanne commented at 10:23 pm on November 5, 2015: none

    The issue still persists even with .0003 :) Right now it is reading through all .ldb-s with total 300-500 kB/s transfer speed which is not a lot for laptop HDD but the daemon is unresponsive to bitcoin-cli getinfo nor to API calls from cgminer. Mem usage is 1.448 GB (started with -dbcachesize=1024). It returns to normal operation only after a while. And then hangs again. I may be wrong and this is just accidental but always when I see it hanged up I see a connection from host naval.nvcube.net which is XT:0.11.0B with an incoming traffic more that from other hosts. Just a blind suspicion, nothing more.
13. 
    NicolasDorier commented at 5:48 am on November 6, 2015: contributor

    Not sure if related, but I also have time to time unresponsive node. If you are running bitcoind in a command line windows, can you go on the windows and hit “Enter” ?

    Agreed, this sound very stupid, but it happened to me several time where hitting Enter in the command line windows of bitcoind just unstuck it… I suspect it was a hardware problem though, I could not replicate on another box.

    For information, yestersday a 0.11 node of mine with 1000 satoshi of txminrelayfee crashed after climbing astronomically high in memory. Using 0.0005 btc fixed the issue though.

14. 
    vayvanne commented at 9:33 pm on November 9, 2015: none

    Today it hanged up for not a long time on the dedicated server with 8 core xeon and 16GB RAM. Increased minrelaytxfee to 0.0003 from 0.0001. Seems DDoS is increasing. The focus with enter seems really working :)
15. 
    NicolasDorier commented at 5:51 am on November 10, 2015: contributor

    I’m happy I’m not alone where the “Focus + Enter” unstuck the node, just can’t get my head around how it might be possible… AFAIK bitcoind does not read the keyboard input at all…
16. 
    vayvanne commented at 0:13 am on November 18, 2015: none

    Issue still persist even with 0.0005. Not that long as in the past and less frequently (once in a few days) though. Increasing to 0.0008. Why it is constantly reading .ldb files? I see no CPU using increase nor the 300-600 kBytes/s input is much even for laptops HDD. I feel like the issue raises when chainstate cache is exhausted. It is 263.5MB with -dbcache=1024 and getmempoolinfo gives 103.8MB and increasing on my server machine at the moment so will check soon. May there be a kind of chainstate cache leak in bitcoind or even memory leak in leveldb?..
17. laanwj added the label Resource usage on Feb 16, 2016
18. MarcoFalke renamed this:
    0.11.0-win64 unresponsive
    0.11.0-win64 unresponsive ("Focus + Enter" workaround)
    on Apr 16, 2017
19. MarcoFalke closed this on Feb 18, 2018

    ---

20. MarcoFalke locked this on Sep 8, 2021

Contributors
vayvanne Diapolo sipa laanwj NicolasDorier

Labels
Windows Resource usage