Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persistent resource consumption due to failure to close JGit objects #61

Open
Freaky opened this issue Feb 20, 2021 · 3 comments
Open

Comments

@Freaky
Copy link

Freaky commented Feb 20, 2021

Investigating a heap dump from a suspiciously bloated backend service found a substantial number of integer arrays owned by live jgit objects.

I suspect this is a result of RJGit failing to close() AutoCloseable JGit objects - to test this hypothesis I've added:

  module RJGit
    class Repo
      def close
        @jrepo.close
      end
    end
  end

And stuffed a call to this in an ensure block. I added a similar change to my variant of RJGit's Commit#stats call to close the DiffFormatter it uses.

After 12 hours the process has grown by about 100MB (post full-GC), which is considerably less than might have been expected prior.

@Freaky
Copy link
Author

Freaky commented Feb 21, 2021

After a day with thousands of commits processed, RES size after a full GC remains stable at ~1.5 GB.

Meanwhile its unpatched cousin is gobbling down 8 GB.

@bartkamphorst
Copy link
Contributor

The evidence certainly seems to support the hypothesis. 😅 Thanks for looking into this. If you have time, would you mind opening a PR with your changes?

@Freaky
Copy link
Author

Freaky commented Feb 22, 2021

I have little more substantial than what's shown, and that requires a change more in applications than in RJGIt.

Thought probably needs to be given as to whether this requires or suggests a change in the API, or whether it can be better served by the use of finalizers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants