Worst case 2.x can consume all available RAM and terminate. It's
generally impossible to rule out worst case, though "normal" consumption
is in the hundreds of MB during catch-up sync, depending on number of peers.

Version 3 is substantially better. During initial block download RAM
consumption is generally under 100MB and barring some other failure it
will not go off the rails.

I'll caveat that with the fact that presently there is a connection leak
in the case repeat connection failures, in which case memory tends to
climb until connections start succeeding. However I don't plan to
release until I have resolved that. The bug is filed against the
libbitcoin-network repo.

During catch-up sync (ie not under checkpoints but not at the top),
version3 memory consumption is peer count dependent, but with a few
peers it starts around 10-20MB and works its way up slowly to a
100-200MB at the top of the chain. This is primarily a function of the
size of the store.

These numbers are based on an 8GM machine. By design performance (speed)
numbers are significantly better with RAM than with less, since the
store is memory mapped. The implementation scales with the amount of RAM
up to the size of the store, at which point other factors are limiting
(network, CPU, SSD, peers).

e


On 10/16/2016 06:51 AM, mlmikael wrote:
> Hi,
>
> What's libbitcoin's RAM consumption characteristics now, how much could
> it occupy in a worst-case situation?
>
> Thanks! :)