What the replay costs
Sampled every 30 seconds on the replay box: resident memory per process, disk held by the fact log and its inputs, and the block rate. The shape matters more than any single number: the replay keeps only the hot part of Arc's state in its heap and reads the rest from memory-mapped snapshot files, a root check runs beside it at every checkpoint, and the fact log's growth per block swings by two orders of magnitude with how busy the chain is.
Memory
The replay does not hold Arc's state in RAM. Its heap keeps the hot set — accounts and slots touched recently, within a fixed budget — and everything else is read from the last checkpoint's snapshot files, memory-mapped. So its resident memory has two parts: the heap (the replay's own) and mapped snapshot pages, which are page cache the kernel can drop and re-read at any time. At each checkpoint the hot set is merged into a new snapshot and evicted, which is what keeps the heap bounded; the root check then reads that snapshot in a separate process.
Disk
The fact log is the product: append-only rows for blocks, transactions, logs, transfers and state diffs. Sealed shards are gzipped behind the live window, which is why its growth is slower than the raw write rate. Snapshots are the verified checkpoints a restart resumes from (the newest two are kept; the newest verified one is also copied off the box daily).
Rate
Blocks per second, both as the replay reports it and as observed between samples — the second survives restarts and shows the gaps. Block rate is not a throughput measure on this chain: a sparse early block and a 50-transaction one differ by two orders of magnitude, so transactions per second is the honest unit and is drawn alongside.