Memory leaks in 0.24

[jellium]

@noisekit

I haven’t found better solution than just restart ipfs daemon from time to time
The longest it lasted was about 6-7 days until ec2 instance became unresponsive and needed a reboot.

Dear,
I encounter the same issue as you describe in this post.
Likewise, I restart the Kubo running virtual machine every few days in order to avoid the daemon to be stopped by oom-kill due to its constant increase of memory usage.
Have you managed to fix this issue for your case?
Regards.

[noisekit]

No solution for me yet. Still restarting the daemon every other day.
After a full machine restart it does no longer eats all memory in 2 days but went back to filling up 8Gb of memory in about a week.

[danieln]

Any chance you can open an issue in the Kubo repo for this? That would be the best way to track this issue.

[mig5]

Hi,

I’m seeing the same sort of memory leaks on the v0.24 version(s). I don’t have the same sort of graphs as the OP, but I have the same oom-kill events every couple weeks.

I have generated a diag profile zip file during a high memory period (as well as the output of the ‘swarm peers’/‘stats provide’ during the same time), and will be happy to share it in a Github issue. Before I do so, though, can a developer please confirm for me that the .zip file would not contain any sensitive data? I kind of don’t know what I’m looking at, and so I didn’t want to upload it anywhere without being sure of that first. Thanks!

[hector]

They don’t contain sensitive data.

Anyone with high mem issues: we need memory profiles per ipfs diag profile. go tool pprof will usually show culprits.

ipfs/kubo/blob/master/docs/debug-guide.md#analyzing-vars-and-memory-statistics