Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19022

GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields

      Hello everyone.

      Months ago, we've noticed a bug/issue with the GIT plug-in. Previously, it was only a minor nuisance but now, it causes each build that we start to use up ~3MB of main memory and ~5MB of disk space in the build.xml.

      The issue is due to the following behaviour of the GIT plug-in:
      For every build that has the GIT SCM defined, it retrieves the list of branches in the remote repository. For each branch, it retrieves the last build in Jenkins that was run against this branch.

      This information is then stored in the Build object in form of the "BuildData" field. This means, that the full list of all branches, plus their last builds is stored in each and every build – thus using up main memory and using up disk space in the "build.xml" file allocated for the build.

      It uses this information to populate a page for the build with the association of branches to builds:
      http://<SERVER>/job/<JOBNAME>/<BUILD-ID>/git/?

      For normal repositories, this data is relatively small, as only a limited number of unmerged branches exist. Unfortunately, we use GIT in an automated manner, where thousands of tags and branches are spawned without merging back into the mainline.

      This means that each build saves several hundred to thousand pointless key-value pairs for GIT branches and Jenkins builds that serve no purpose whatsoever.

      In our case, this means – as outlined above – we waste 3MB of RAM per build and 5 MB of disk space. With 10k builds per day, you can imagine that this is quite a predicament.

      As a workaround, we've written a Jenkins job that removes the tags contained in "<hudson.plugins.git.util.BuildData>" in the "build.xml". This cuts down its size from 5MB down to 16kB (~0.156MB). This of course also greatly boosts the speed of deserealizing the builds from disk.

      Our request would be: Either remove the collections/deserialization of this (from our POV) pointless data, or make its generation optional via a configuration option.

      Best regards,
      Martin Schröder
      Intel Mobile Communications GmbH

          [JENKINS-19022] GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields

          Martin Schröder created issue -

          Martin Schröder added a comment - - edited

          This issue will be fixed as soon as the following pull request has been merged & rolled-out:

          https://github.com/jenkinsci/git-plugin/pull/163

          Martin Schröder added a comment - - edited This issue will be fixed as soon as the following pull request has been merged & rolled-out: https://github.com/jenkinsci/git-plugin/pull/163

          Working on https://github.com/jenkinsci/git-plugin/tree/builddata for a fix,

          • use a shared object for BuildData, vs one instance per build
          • integrate with PruneStaleBranch to delete obsolete data.

          Nicolas De Loof added a comment - Working on https://github.com/jenkinsci/git-plugin/tree/builddata for a fix, use a shared object for BuildData, vs one instance per build integrate with PruneStaleBranch to delete obsolete data.

          Thanks again for your work on this topic, Nicolas!

          Martin Schröder added a comment - Thanks again for your work on this topic, Nicolas!

          Jeff Skjonsby added a comment -

          I think centralizing the BuildData may fix JENKINS-18588 also.

          Jeff Skjonsby added a comment - I think centralizing the BuildData may fix JENKINS-18588 also.

          Scott Hebert added a comment -

          Hi,

          As a workaround, I have created a groovy script that removes the BuildsByBranch map and persists the reduced Build object to disk.

          It can be found here: http://scriptlerweb.appspot.com/script/show/326001

          This script can be used as a System Groovy script step in a job or simply run periodically via the script console.

          Feedback is welcome!

          Scott Hebert added a comment - Hi, As a workaround, I have created a groovy script that removes the BuildsByBranch map and persists the reduced Build object to disk. It can be found here: http://scriptlerweb.appspot.com/script/show/326001 This script can be used as a System Groovy script step in a job or simply run periodically via the script console. Feedback is welcome!

          Scott Hebert added a comment -

          Hi,

          I have updated http://scriptlerweb.appspot.com/script/show/326001 to support Matrix Project types.

          Thanks

          Scott

          Scott Hebert added a comment - Hi, I have updated http://scriptlerweb.appspot.com/script/show/326001 to support Matrix Project types. Thanks Scott

          Scott Hebert added a comment -

          I migrated the script to https://wiki.jenkins-ci.org/display/JENKINS/Remove+Git+Plugin+BuildsByBranch+BuildData

          The latest update includes a fix to better support SCM polling.

          Scott Hebert added a comment - I migrated the script to https://wiki.jenkins-ci.org/display/JENKINS/Remove+Git+Plugin+BuildsByBranch+BuildData The latest update includes a fix to better support SCM polling.
          Mark Waite made changes -
          Link New: This issue is duplicated by JENKINS-30873 [ JENKINS-30873 ]

          Norbert Thiebaud added a comment - - edited

          Thanks Scott for making the script available.
          Got hit hard by this bug.... to a point were the instance was unusable
          I finally found this bug report and your script.. it saved the day, thanks again.

          Norbert Thiebaud added a comment - - edited Thanks Scott for making the script available. Got hit hard by this bug.... to a point were the instance was unusable I finally found this bug report and your script.. it saved the day, thanks again.

            Unassigned Unassigned
            mhschroe Martin Schröder
            Votes:
            40 Vote for this issue
            Watchers:
            90 Start watching this issue

              Created:
              Updated: