<p>I noticed the same behavior with a x86 cpu (j5005).</p>
<p><code>b-msghand</code> is a network thread that handles &quot;application level message (sending and receiving). Almost all net_processing and validation logic runs on this thread.&quot;</p>
<p>So my solution has been to reduce <code>-maxconnections</code> to 60 (from the default 125) and I have never seen it again using 100% of 1 core.</p>

CC BY-SA 4.0
2023-05-08T16:27:27.293Z
2023-05-08T16:27:27.293Z
Miliki
<p>I started playing with bitcoind 0.18.1 on a RPI4 and i can see that even when fully synced it is still using 100% cpu so one full core.</p>

<p>Is this normal / expected ? </p>

<p>Looking at the threads is the <code>bitcoin-msghand</code> (ler?) thread that is doing the work</p>

<pre><code> 5946 999       20   0  557016 410080   3392 R  98.8  10.2 226:58.92 bitcoin-msghand       
</code></pre>

<p>could it be that my <code>dbcache=100</code> is causing it to do much IO while relaying data to other peers ? 
To be fair i don't see much IO at all </p>

<p>thanks!</p>

<bitcoind><raspberry-pi>
Fully synced bitcoind 0.18.1 on RPI4 using 100% cpu ( 1 core only ) , is it normal?
przRocco
# Fully synced bitcoind 0.18.1 on RPI4 using 100% cpu ( 1 core only ) , is it normal?

(Asked by: username_0 on 2019-10-27)

I started playing with bitcoind 0.18.1 on a RPI4 and i can see that even when fully synced it is still using 100% cpu so one full core.
Is this normal / expected ? 
Looking at the threads is the bitcoin-msghand (ler?) thread that is doing the work
 5946 999       20   0  557016 410080   3392 R  98.8  10.2 226:58.92 bitcoin-msghand       

could it be that my dbcache=100 is causing it to do much IO while relaying data to other peers ? 
To be fair i don't see much IO at all 
thanks!

**Tags:** bitcoind, raspberry-pi


---

## 1 answers

### Answer by username_1 on 2023-05-08. Score: 0

I noticed the same behavior with a x86 cpu (j5005).

`b-msghand` is a network thread that handles "application level message (sending and receiving). Almost all net\_processing and validation logic runs on this thread."

So my solution has been to reduce `-maxconnections` to 60 (from the default 125) and I have never seen it again using 100% of 1 core.


---

