A combination of Gerrit trigger and Git plugins leaks a lot of hudson.plugins.git.util.Build entries in some build.xml files and there can be thousands of them in there over time. There is a bug <https://issues.jenkins-ci.org/browse/JENKINS-19022> that talks about such issues with branches, but in my case the entries in build.xml file look like following:

 <entry>
 <string>refs/changes/12/123456/10</string>
 <hudson.plugins.git.util.Build>
 <marked plugin="git-client@2.5.0">
 <sha1>1234567890123456789012345678901234567890</sha1>
 <branches class="list">
 <hudson.plugins.git.Branch>
 <sha1 reference="../../../sha1"/>
 <name>refs/changes/12/123456/10</name>
 </hudson.plugins.git.Branch>
 </branches>
 </marked>
 <revision plugin="git-client@2.5.0">
 <sha1 reference="../../marked/sha1"/>
 <branches class="list">
 <hudson.plugins.git.Branch reference="../../../marked/branches/hudson.plugins.git.Branch"/>
 </branches>
 </revision>
 <hudsonBuildNumber>12345</hudsonBuildNumber>
 </hudson.plugins.git.util.Build>
 </entry>

I have seen almost 10000 entries of such entries in some build.xml files that were referencing to Gerrit changes from over 3 months ago before I started running the script shown here <https://wiki.jenkins.io/display/JENKINS/Remove+Git+Plugin+BuildsByBranch+BuildData>. There is maximum of 2 week retention period for in the two of the Jenkinses that this happens. They both have the same Git and Gerrit trigger plugin versions, although the Jenkins version is different. But they both exhibit similar symptoms where for some jobs those build.xml files just explode over time.

Running this build.xml cleaner every hour seems to keep the worst case situation under control, as the number of worst case scenario build entries starts again from 1 until it reaches around 100 in 1 hour and drops to 1 again.