Skip to content

Optimize garbage collector behavior #3328

@aawsome

Description

@aawsome

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 GOGC parameter 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 👍

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: discussionundecided topics needing supplementary input

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions