Known Memory Leaks

[Stebalien]

This issue exists to track known memory leaks and their statuses. A memory leak is defined as a case where memory grows unbounded (intentionally or not) over time.

Peerstore

The peerstore is currently stored in memory by default and not all values are garbage collected.

For every peer we've ever connected to, we remember:

• Known protocols (medium)
• Public keys (medium)
• Peer IDs (minor)
• User agents/versions (minor)

For recently connected peers, we remember (not technically a leak as we do GC eventually):

• All addresses reported by that peer (could be quite a few).

Solutions:

• Switch to storing peerstore data on disk. This is currently possible but hasn't been thoroughly tested for performance.
  • Issue: peerstore: next steps for datastore-backed peerstore #1702
• Stop permanently storing metadata we don't need. Known protocols, public keys, etc. are only really useful while we're connected and we always re-learn them when we reconnect. We may eventually need to remember these longer but we shouldn't leak memory now for something we may need later (and could choose to store later).
  • Issue: Forget unnecessary metadata on disconnect go-libp2p-peerstore#93

Metrics

We collect bandwidth (and other) metrics that we don't always do a good job of cleaning up.

• For every protocol we've ever spoken, we remember how much bandwidth the protocol has used. (negligible for now)
• For every peer we've connected to, we remember how much bandwidth (in/out) the peer has used. (minor)

Solutions:

• Metrics can be entirely disabled in the libp2p constructor.
• We could implement a sweeper that removes metrics that haven't been touched in some time period.

---

Libp2p team: Please update this as we find new issues and resolve old ones.

[marten-seemann]

This was fixed in the v0.17.0 release.