Bitcoin full node and query server

Oct 30, 2024

View in context in the libbitcoin Slack #general mirror.

evoskuil03:45
Validating now on the big box. This is a test of validation after download (small box target) with read ahead caching of 1024 blocks, to ensure that the CPU is never starved. 64 threads at 100% (block.accept() and block.connect()), disk reading at 100% (block read and prevout population) and writing almost nothing (block state entry). [first image] As block size increases (in order), memory will fill up with table pages but will not thrash (reading only) and disk reads will vary to maintain the read-ahead block/prevout cache. [second image] All that work we did up to this point is to get here so we can validate at 100%, because it doesn't get any faster than that.
image.pngimage.png
2 replies · evoskuil · last Oct 30, 2024
evoskuil05:28
It's not actually 1024 blocks, it's 1024 * 5000 txs (simulating 1024 very full blocks by tx count, even if blocks are empty).
evoskuil13:15
On Windows at least, the OS will just retain the maps until something else wants the memory. No point at all in freeing it up. So the query response remains optimal even when it's been idle overnight.
image.png