bitcoind consumes 100% cpu when offline (can’t connect to peers) #6903

1. 
   mcelrath commented at 3:00 pm on October 29, 2015: none

   CAddrMan::Select_ contains two infinite loops, trying to find peers. The float fChanceFactor becomes very large = 1.2^n after n loops, while info.GetChance() returns a very small number, 10^-324.
2. laanwj added the label P2P on Oct 31, 2015
3. 
   gmaxwell commented at 11:08 pm on November 22, 2015: contributor

   What you’re describing with very small probabilities I mostly fixed in a784f90c a long time ago. What code are you actually seeing this in?
4. 
   laanwj commented at 12:23 pm on February 16, 2016: member

   Related issue: #1664 (it was solved back then, at least, as gmaxwell says)
5. 
   str4d commented at 4:10 am on May 11, 2016: contributor

   Zcash users are seeing this behaviour on our testnet (our corresponding issue is zcash/zcash#717). We are based off 0.11.2; it does appear that there have been slight changes to Select_() in the intervening time, but nothing that appears to alter the break condition for the infinite loop.
6. 
   str4d commented at 6:58 am on June 3, 2016: contributor

   We have a proposed fix for this now (zcash/zcash#929). It would be great to have your thoughts on it @gmaxwell (and if desired we can make a PR for here :smiley:)
7. 
   laanwj commented at 8:40 am on June 9, 2016: member

   Thanks for mentioning @str4d
8. laanwj added the label Resource usage on Jun 9, 2016
9. 
   ghost commented at 6:20 pm on July 19, 2019: none

   I can confirm this issue. I am sad to see that this issue has been opened nearly four years ago and is still open.

   Running bitcoind v0.18.0 full node with bitcoin.conf:

   0onlynet=onion
   1onion=127.0.0.1:9050
   2listen=1
   

   I think it would be much smarter and better, if bitcoind would detect network unreachability and then go into some sleepy connection testing loop, until connection is detected as up again. This would prevent unhealthy CPU and therefore electrical power usage.

10. 
    MarcoFalke commented at 8:31 pm on July 19, 2019: member

    @wodry What are the steps to reproduce, please?

    Which OS are you running. What version of tor? Does it happen when you start the node without a connection or does it only happen when you initially had some connections?

11. 
    ghost commented at 8:32 am on July 20, 2019: none

    Oh yes, sorry, of course:

    Bitcoin-qt: bitcoin-0.18.0-x86_64 from binary tar ball OS: Debian GNU/Linux 9.8 (stretch), all packages up to date. Kernel: 4.9.0-8-amd64 [#1](/bitcoin-bitcoin/1/) SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux Tor: 0.2.9.16-1

    The 100% CPU usage also happens maybe 10 minutes after having started bitcoin-qt when DSL cable was initially already cut off (and therefore local running Tor had already lost connection).

    Steps to reproduce:

    Run local Tor with following config

    /etc/tor/torrc

    0ClientOnly 1
    1
    2ClientUseIPv6 1
    3
    4ReachableAddresses *:53,*:80,*:443,*:6667,*:8333,*:9001,*:9030
    5
    6BandwidthRate  3 MBit
    7BandwidthBurst 5 MBit
    

    The user that runs Bitcoin-qt has to be in the group debian-tor so bitcoin-qt can start Tor Hidden Service automatically.

    Run Bitcoin-qt (no connections inbound from internet to any ports like 8333 allowed) with following config

    ~/.bitcoin/bitcoin.conf

     0upnp=0
     1
     2onlynet=onion
     3onion=127.0.0.1:9050
     4listen=1
     5maxuploadtarget=400
     6
     7# Specify connection timeout in milliseconds
     8timeout=20000
     9
    10# Accept command line and JSON-RPC commands
    11server=1
    

    Let bitcoin-qt run some days and then disconnect network cable, wait approx. 1 hour or Have only Tor running, then disconnect netwotk cable and then start bitcoin-qt and wait 10 minutes (last debug.log messages: “0 addresses found from DNS seeds”, “dnsseed thread exit”)

    -> CPU usage of bitcoin-qt process is constantly 100%

    Connect network cable

    -> after some time (1h or so) Tor detects network as up again, bitcoin-qt has connection again (messages: “Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)”, “New outbound peer connected: version: 70015”), and the CPU usage reduces to normal low value.

12. 
    ghost commented at 9:02 pm on August 9, 2019: none

    The issues seems to be solved with bitcoind 0.18.1. Maybe #16405 fixed it?

    With 0.18.1 CPU usage stays now low when internet connection goes down, and when internet connection is up again, at once bitcoind detects it and connects to new outbound peers. So behavior is now really smooth. From my point of view, this issue can be closed.

13. 
    promag commented at 9:10 pm on August 9, 2019: member

    @wodry #16405 fix in unrelated to this issue.
14. 
    MarcoFalke commented at 8:17 pm on April 24, 2020: member

    The issues seems to be solved with bitcoind 0.18.1.

    Closing for now

15. MarcoFalke closed this on Apr 24, 2020

    ---

16. DrahtBot locked this on Feb 15, 2022

Contributors
mcelrath gmaxwell laanwj str4d ghost MarcoFalke promag

Labels
P2P Resource usage