On 06/04/2015 03:29 AM, mlmikael wrote:
> On 2015-06-03 09:24, Neill Miller wrote:
>> On Tue, May 26, 2015 at 11:00:27PM -0700, Eric Voskuil wrote:
>>> I've recently merged a change to libbitcoin-node which cleans up
>>> logging. There are a few misleading log messages pertaining to blocks.
>>> There are actually no errors and the behavior I see is normal, so I've
>>> changed the descriptions and locations of the messages so they are more
>>> obvious and appropriate. The only actual errors I ever see pertain to
>>> connection failures, but nothing that appears unusual.
>>
>> I need to look into your recent updates, as I've been mucking with the
>> networking lately and am finally at the point where I can sync testnet
>> with an updated protocol version. Haven't tested mainnet yet, but I
>> will after some cleanups.
>>
>>> I think at this point that stall is due to not getting a necessary
>>> block, and the memory consumption results from accumulating subsequent
>>> blocks into the orphan pool. Sometimes this is steep and other times
>>> minimal. When the block is obtained the stall clears, but high memory
>>> consumption can severely degrade performance and the process can get
>>> killed before the stall clears. I'm going to add some instrumentation
>>> now so I can monitor the orphan pool and block requests.
>>
>> The stalls are still a factor, so we can safely separate them from a
>> protocol issue. The currently isolated repeatable stall I can get (on
>> my working tree) is when a block is failing to be accepted for some
>> reason and it doesn't seem to clear until something drastic happens
>> (i.e. at least a rebuild/restart) rather than just waiting and
>> waiting. Still haven't narrowed it down any further, but I suspect
>> it'll turn up at some point now that we're looking for it.
>>
>> -Neill.
>
> Wait, this current worst bug known (so that is the stall bug), what is
> its worst possible consequence -
>
> LB really operates as it should so it's not visible to the user (bx
> etc.).
>
> And it's known to *always* automatically solve soon enough.
>
> So its absolutely worst consequence then is peaks of 1-2GB of more RAM
> consumption than really needed?
>
> Thank

It is apparently possible to get synced, but I have never been able to
get there. Doing so requires lots of patience/effort/skill. There is no
observable limit the the RAM consumption that may occur. It's also
likely that the server may periodically fall behind while operating
after initial sync.

e