Bitcoin full node and query server

Jun 11, 2024

View in context in the libbitcoin Slack #general mirror.

evoskuil23:18
Confirmation reads are sprawling, but there is very little data actually collected. The input and output tables, which contain the bulk of blockchain data aren't touched, since they are not hash tables (just blob tables referenced from others). So while there is a large amount of querying, data quickly populates RAM and disk activity slows significantly. It's dropped from 300MiB/s to 50MiB/s, with a disk capacity of 530MiB/s. Over a span of the top 7,500 blocks, confirmation speed accelerated to 6.85 blocks/sec. Concurrency at full disk capacity (only about 1% of CPU is currently being used, on single thread) would put this at about 68 blocks/sec or 2,941 sec (49 minutes) for the full 1B txs). That assumes a good amount of RAM to limit page swaps. I had reached about 100GiB (with no swapping because I have 128GiB). But it's a low end SSD and in this example requires only 10 threads. It also assumes no concurrency with download and/or validation.