<p>It is probably downloading the whole blockchain locally. It will take hours to complete.</p>

<p>the command  <code>bitcoin-cli getinfo</code> will display the information you're looking for.</p>

<p>If you want to see all available commands: <a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list</a></p>

CC BY-SA 3.0
2017-09-03T15:39:23.370Z
2017-09-03T15:39:23.370Z
VP.
<p>For slightly better insight into what your node is doing, try tailing .bitcoin/debug.log</p>

CC BY-SA 3.0
2017-12-01T05:13:21.667Z
While I think this is useful information, a bit more explanation would be appreciated.
Murch
CC BY-SA 3.0
2017-11-30T18:03:38.613Z
2017-11-30T18:03:38.613Z
EvilDave
<p>If you're running Bitcoin Core (I'm not sure when this feature was introduced, I'm running 0.15.1), in the .bitcoin directory you should find a file called debug.log which records contacts with peer nodes and transfer of blockchain blocks. The information here is useful when the blockchain is being transferred to your machine for the first time because it gives a sense of how quickly blocks are arriving and how far you have to go. </p>

<p>Example block arrival record:</p>

<p>2017-11-29 14:49:06 UpdateTip: new best=00000000000000000106ae17dcccd5a0bde5ea3e47d255bd140e521719c6e4c5 height=481133 version=0x20000002 log2_work=86.959389 tx=247718348 date='2017-08-18 19:35:03' progress=0.899967 cache=225.9MiB(1826706txo)</p>

<p>When your blockchain is incomplete, the progress value is roughly the fraction of the blockchain you've received. height is the actual number of blocks currently in your blockchain.</p>

<p>If you're seeing high network and disk utilization, the odds are you're still receiving the initial blockchain transfer. In terms of figuring out long receiving the entire blockchain will take, note that as the blockchain height increases, the time to get additional blocks increases (not sure why). Allow more time than simple multiplication of delay between blocks and blocks to go would suggest.</p>

<p>You will need a lot of disk to run a full node. At the time of this writing, the blockchain height is 497132 and the .bitcoin directory occupies 175GB (txindex=1).</p>

<p>Update: running bitcoind with -debug will dump a ton of debugging info into debug.log. To just see the actual transactions you're getting run bitcoind with your usual flags and "-debug=mempool -debug=mempoolrej"</p>

CC BY-SA 3.0
2017-12-02T02:05:15.410Z
2017-12-15T06:16:40.877Z
2017-12-15T06:16:40.877Z
EvilDave
<p>I am aware of (I'm avoiding the term understand) the functions of transmitting/validating transactions/blocks but mainly trying to understand the resource utilization of my machine running the full node.</p>

<p>I have bitcoind running on Ubuntu16.04 Server so I have limited visibility into its activity beyond htop, iostat, etc. For the first time ever, I wish I was running Ubuntu Desktop and may do so unless you can recommend some tools for visibility into bitcoind activity.</p>

<p>But back to the subject, I currently only have 1 virtual CPU out of 8 available hyperthreaded cores on an i7 assigned along with 4G of ram, a single consumer grade disk, and a 60mb internet connection. I've confirmed inbound connections with bitcoind-cli getpeerconnectioncount to be 15-20 at any given time.</p>

<p>My disk thrashes like it could burn up at any time. My network connection constantly spikes up to 100%'ish of my inbound bandwidth such that I had to shut down bitcoind to watch a stream of a football game yesterday in decent res.</p>

<p>But my cpu and memory do almost nothing at all. Resource utilization is effectively nil.</p>

<p>So really an academic question as to what this node is doing to result in that footprint.</p>

<full-node>
So what exactly is my full node doing?
RuMORDeN
# So what exactly is my full node doing?

(Asked by: username_0 on 2017-09-03)

I am aware of (I'm avoiding the term understand) the functions of transmitting/validating transactions/blocks but mainly trying to understand the resource utilization of my machine running the full node.

I have bitcoind running on Ubuntu16.04 Server so I have limited visibility into its activity beyond htop, iostat, etc. For the first time ever, I wish I was running Ubuntu Desktop and may do so unless you can recommend some tools for visibility into bitcoind activity.

But back to the subject, I currently only have 1 virtual CPU out of 8 available hyperthreaded cores on an i7 assigned along with 4G of ram, a single consumer grade disk, and a 60mb internet connection. I've confirmed inbound connections with bitcoind-cli getpeerconnectioncount to be 15-20 at any given time.

My disk thrashes like it could burn up at any time. My network connection constantly spikes up to 100%'ish of my inbound bandwidth such that I had to shut down bitcoind to watch a stream of a football game yesterday in decent res.

But my cpu and memory do almost nothing at all. Resource utilization is effectively nil.

So really an academic question as to what this node is doing to result in that footprint.

**Tags:** full-node


---

## 3 answers

### Answer by username_1 on 2017-09-03. Score: 1

It is probably downloading the whole blockchain locally. It will take hours to complete.

the command `bitcoin-cli getinfo` will display the information you're looking for.

If you want to see all available commands: <https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list>


---

### Answer by username_2 on 2017-11-30. Score: 1

For slightly better insight into what your node is doing, try tailing .bitcoin/debug.log

> **Comments:**
> **username_3**: While I think this is useful information, a bit more explanation would be appreciated.  

---

### Answer by username_2 on 2017-12-02. Score: 0

If you're running Bitcoin Core (I'm not sure when this feature was introduced, I'm running 0.15.1), in the .bitcoin directory you should find a file called debug.log which records contacts with peer nodes and transfer of blockchain blocks. The information here is useful when the blockchain is being transferred to your machine for the first time because it gives a sense of how quickly blocks are arriving and how far you have to go.

Example block arrival record:

2017-11-29 14:49:06 UpdateTip: new best=00000000000000000106ae17dcccd5a0bde5ea3e47d255bd140e521719c6e4c5 height=481133 version=0x20000002 log2\_work=86.959389 tx=247718348 date='2017-08-18 19:35:03' progress=0.899967 cache=225.9MiB(1826706txo)

When your blockchain is incomplete, the progress value is roughly the fraction of the blockchain you've received. height is the actual number of blocks currently in your blockchain.

If you're seeing high network and disk utilization, the odds are you're still receiving the initial blockchain transfer. In terms of figuring out long receiving the entire blockchain will take, note that as the blockchain height increases, the time to get additional blocks increases (not sure why). Allow more time than simple multiplication of delay between blocks and blocks to go would suggest.

You will need a lot of disk to run a full node. At the time of this writing, the blockchain height is 497132 and the .bitcoin directory occupies 175GB (txindex=1).

Update: running bitcoind with -debug will dump a ton of debugging info into debug.log. To just see the actual transactions you're getting run bitcoind with your usual flags and "-debug=mempool -debug=mempoolrej"


---

