1

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.

Improve this question

3 Answers 3

Reset to default
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

Improve this answer
1

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

Improve this answer
1
  • 1
    While I think this is useful information, a bit more explanation would be appreciated.
    – Murch ♦
    Dec 1, 2017 at 5:13
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"

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.