Update graphsync & fix in-progress request memory leak by consuming responses

[hannahhoward]

Goals

Resolve major in process request memory usage by updating graphsync (work done in repo) and consuming in progress graphsync response channel.

Implementation

• Update graphsync to v0.4.1 -- there was an issue with backpressure that resulted in a large accumulation of memory on the responding side of graphsync requests. This has now been resolved.
• Add consuming of response channel to consumeResponses method on Graphsync transport -- the problem here is that graphsync intentionally buffers this channel for you, so you can consume it at your leisure without locking the graphsync implementation. The problem is if you done't consume the response channel the buffer accumulates till the request completes. For a very large request this can be catastrophic. There's possibly a potential design issue here, but for the time being the simple solution is to consume the channel.

For discussion

Here are heap profiles of in use memory objects assembled by running:

go test -v -bench=BenchmarkRoundtripSuccess/test-p2p-stress-1-1GB-no-raw-nodes$ --memprofile=profile.out

Essentially, we're running a 1GB data transfer over a connection gated at 16MB per second -- it will stop in the middle after 10 seconds, and we take the heap profile here.

First, with graphsync v0.3.1:

Note the two areas in red -- the one on the left is memory use on the responder side and the one on the right is memory use on the requestor side.

Now, with graphsync v0.4.1:

The responder side memory usage is massively reduced (the worst issue) but we still have accumulated data on the requestor side.

Now, adding consuming the response channel in go-data-transfer:

The requestor side memory usage is gone.

[aarshkshah1992]

@hannahhoward Don't we need to do anything with the responses here ? Who are these responses intended for ?

[hannahhoward]

It's another way to read response data -- in direct IPLD node format. They are still saved to the blockstore anyway so we don't need to do anything with them

[aarshkshah1992]

LGTM module one question.