These figures are measured on a real import of chain 2800, not estimated. Where a number moves with the height of the chain, that is said rather than averaged away.
Memory
8 GB is the floor at which a full from-genesis import stops being practical, not a comfortable size. 16 GB gives the database the room the measurement shows it wants.
The requirement is not flat. It grows with the height, because the storage engine's working set grows with the chain. Measured on an 8 GB machine: past 12.2 million blocks the process sat at 5.96 GB resident with a 3.4 GB heap, the old generation 99.8% full, and four full garbage collections in five minutes.
Heap: bigger is not faster
The same -Xmx flag was measured at four values on the same machine:
-Xmx | What the JVM did | Blocks per minute |
|---|---|---|
| 4500m | 89 OutOfMemoryError, 7.1 GB resident, import stopped dead | 0 |
| 3200m | Ran, then degraded with repeated out-of-memory errors | ~1,500 |
| 2400m | Healthy early, 1,409 full collections past 9.19 M | ~82,000 early, ~640 late |
| 3400m | Zero full collections past nine million | ~28,800 |
The reason a larger heap is slower is that the storage engine's block cache lives outside the heap. A heap that takes the memory the database also needs starves it, and the process spends its time collecting instead of importing.
So do not pick a fraction of RAM and hope. Watch it:
jstat -gcutil <pid> 5000 3If the old generation sits near 100% and full collections are frequent, the heap is too small. If you see OutOfMemoryError in the log, it is too large for what the database also needs: lower it. On 8 GB the band that worked was roughly 2.4 GB early and 3.4 GB past nine million blocks, and the optimum moves as the chain grows.
Disk
Headers are roughly 95% of a node's disk on chain 2800. Blocks are mostly empty, so there are few transactions, receipts or state to store.
Anchor headers are the exception and they are large: every 128th header carries a post-quantum certificate of tens of kilobytes. Size from the measured header, never from the minimum seal count, because nodes attach as many valid seals as arrive rather than the minimum required.
Growth is best measured as size divided by height over the life of the database, not over a short window. A compacting database can report zero growth for eighteen minutes and tens of kilobytes per block over the next eighteen.
Measure a database's growth withduon its directory, never withdfon the filesystem.dfmeasures the whole filesystem, so it counts every other thing that changes on that disk, including whatever you copied there yourself, and will attribute it to the chain.
Network
Outbound and inbound TCP and UDP on your peer-to-peer port. Discovery is UDP; a TCP-only opening gives you a node that never finds peers and looks broken for no visible reason.