RUN-A-NODE: the measured RAM figure for a from-genesis import. The requirement grows with the height: the same import that ran comfortably at 3 M blocks was, at 12.2 M, using 5.96 GB resident with a 3.4 GB heap, old generation 99.8 percent full, four full GCs every five seconds, and no room left to raise the heap. 8 GB is the floor at which a full import stops being practical, not a comfortable size
This commit is contained in:
parent
84a6093517
commit
b46c815398
@ -179,6 +179,15 @@ and the node dies of `OutOfMemoryError`. But a heap that is too small is just as
|
||||
direction: past block 9,189,161, where the post-quantum precompiles go live, blocks get heavier, the old
|
||||
generation fills, and the node spends its time in full GC instead of importing.
|
||||
|
||||
**How much RAM a from-genesis import needs, measured.** The requirement is not flat: it grows with the
|
||||
height, because the storage engine's working set grows with the chain. On the machine above (8 GB for
|
||||
the node), the same import that ran comfortably at three million blocks was, at 12.2 million, using
|
||||
5.96 GB of resident memory with a 3.4 GB heap, with the old generation 99.8% full and four full GCs
|
||||
every five seconds - and there was no room left to raise the heap without hitting `OutOfMemoryError`
|
||||
instead. Treat 8 GB as the floor at which a full from-genesis import stops being practical, not as a
|
||||
comfortable size; 16 GB gives the database the room this measurement shows it wants. Following the
|
||||
live tip, once synced, needs far less: the network's own reading nodes do it inside their normal
|
||||
footprint.
|
||||
So do not pick a fraction of RAM and hope. Watch it: `jstat -gcutil <pid> 5000 3` prints one line every
|
||||
five seconds. If `FGC` climbs while the height barely moves, the heap is too SMALL - raise it. If you see
|
||||
`OutOfMemoryError` in the log, it is too LARGE for what the database also needs - lower it. On 8 GB, the
|
||||
|
||||
Loading…
Reference in New Issue
Block a user