go-waku
go-waku copied to clipboard
fix: GC peer records
Description
While debugging this issue https://github.com/waku-org/waku-rust-bindings/issues/86 I found out that the peerstore keeps the records in memory permanently, and only removes multiaddresses depending on the TTL. With this PR, periodically i check whether the records stored in the peerstore don't have a multiaddress, if that's the case, i remove the peer from the store completely (removing also all metadata like the enr and origin).
Also I update go-discover version since it might contain changes that help with the memory usage of discv5
Jenkins Builds
:grey_question: | Commit | :hash: | Finished (UTC) | Duration | Platform | Result |
---|---|---|---|---|---|---|
:heavy_multiplication_x: | 5e78f776 | #1 | 2024-02-12 18:59:43 | ~2 min | nix-flake |
:page_facing_up:log |
Except statically added peers, all other peer addresses are expired after AddressTTL which is defaulted to 1 hour. I am not sure if this change fixes anything.
Do we have any data showing addresses are not expiring or peerstore size is growing indefinitely?
Right, i missed the call to flush() in https://github.com/libp2p/go-libp2p/blob/master/p2p/host/peerstore/pstoreds/addr_book.go#L48-L70 so probably the commit related to the removing the peer can be removed.
The reason why I think the peerstore is growing is because pprof's alloc_space is displaying this:
...
Interestingly enough, I see in pprof's inuse_space is that leveldb's seems to represent ~50% of the memory usage
I have an instance of go-waku running in http://64.225.21.1:51249/debug/pprof/ , i resetted it today, with this PR. Let's see after a couple of days if updating go-discover helped somehow.
The reason why I think the peerstore is growing is because pprof's alloc_space is displaying this:
Interesting that TTL and memory free are not getting captured by pprof. Could it be due to go's internal memory management?