On 05/31/2015 11:36 PM, mlmikael wrote:
> On 2015-06-01 05:00, Eric Voskuil wrote:
>> On 05/29/2015 01:47 PM, mlmikael wrote:
> ...
>> I've found that the orphan pool and transaction pool during sync are
>> generally empty, although the orphan pool can spike. The larger memory
>> variations are from internal asynchronous message queuing.
>>
>> What we see is the network operations continue even on the stalled
>> strand (accumulating memory), and operations continue that are not
>> ordered by the stalled strand, like heartbeat. And eventually the
>> stalled strand will clear, freeing up its accumulated blocks and
>> transactions. I don't think anything is leaking, but because the node
>> continues to ask for and obtain blocks and transactions, it can generate
>> quite a backlog if the strand is held up.
>
> What's the best way to counteract this, so that the spike is capped to
> a pre-set X MB +-10%?

Well managing the resources available to a process is the job of the
operating system. An application can be more or less efficient, but
self-imposed resource constraints don't make a lot of sense to me - you
end up duplicating the functions of the OS. If RAM runs low then
performance will degrade through the increased use of virtual memory.
The operating system always has the option to terminate a process.
Measuring performance under anticipated conditions is the best way to
determine resource usage. The code exposes tuning parameters that allow
one to optimize for various tradeoffs.

However the scenario above does raise an important question regarding
denial of service. We want to make sure that peers can't cause order of
magnitude increases in resource consumption. But this is a different
question than constraining overall resource consumption.

e