-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Optimize garbage collector behavior #3328
Description
Output of restic version
restic 0.12.0 (v0.12.0-6-g70568c5b-dirty) compiled with go1.14.7 on linux/amd64
What should restic do differently? Which functionality do you think we should add?
From time to time, users get trouble with memory usage of restic. There have been many improvements in the recent time which tackled the data structures and internal memory representation of those as well as algorithmic optimizations which also led to decreased memory.
However, in the forum there are still situations where users need to play around with the GOGC environment variable to squeeze out the least bytes of unused memory to let restic run successfully, see e.g. here.
As restic is no real-time application, garbage collection runs do not hurt and can be done quite often without much trouble. So I want to discuss if we should implement more GC runs within restic. I can think of two approaches:
- Set the
GOGCparameter to a (suitable) low value using SetGCPercent. This would however prevent users from manually setting it to an even lower value, if needed. - Identify "critical" points in the program logic where a GC run would be able to remove lots of temporary used data and manually run
runtime.GC(). This could be e.g. after loading the index into memory.
Both approaches can be implemented independently.
What are you trying to do? What problem would this solve?
Optimize the memory usage profile. Improve the end-user experience.
Did restic help you today? Did it make you happy in any way?
Keeps my data safe without any trouble for quite a long time now 👍