<https://lh3.googleusercontent.com/-251S4LpMJnI/V17JlyXG5II/AAAAAAAAAfg/04-FsQ6YJtYOzB70Ll78Myhsd9kSsPATgCLcB/s1600/LogRotator.png>
On Monday, 13 June 2016 16:49:56 UTC+2, Jimilian wrote:
>
> Hi!
>
> We had some issues with Jenkins last days and after some profiling I found
> that root cause is how Jenkins perform log rotation.
>
> LogRotator.java (1.609.3):
> if(numToKeep!=-1) {
> // Note that RunList.size is deprecated, and indeed here we
> are loading all the builds of the job.
> // However we would need to load the first numToKeep anyway,
> just to skip over them;
> // and we would need to load the rest anyway, to delete them.
> // (Using RunMap.headMap would not suffice, since we do not
> know if some recent builds have been deleted for other reasons,
> // so simply subtracting numToKeep from the currently last
> build number might cause us to delete too many.)
> List<? extends Run<?,?>> builds = job.getBuilds();
> for (Run r : copy(builds.subList(Math.min(builds.size(),
> numToKeep), builds.size()))) {
> if (shouldKeepRun(r, lsb, lstb)) {
> continue;
> }
> LOGGER.log(FINE, "{0} is to be removed", r);
> r.delete();
> }
> }
>
> I think it's much better to keep "numToKeep - X" or "numToKeep + X" jobs
> instead of loading and processing all builds.
> Because now it creates a huge... HUGE... memory footprint:
>
>
> Maybe it's possible to change this behavior? Create a additional option or
> something like that? Because right now we have only one solution - use date
> based rotation instead of number of builds based.
>
> Br, Alex
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/5010e3bd-4b73-4df1-a869-47e20ecdddf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
