Unexpected memory footpring from LogRotator

[Jimilian]

Hi!

We had some issues with Jenkins last days and after some profiling I found
that root cause is how Jenkins perform log rotation.

{code}
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();
}
}
{code}

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:
<http://jenkins-ci.361315.n4.nabble.com/file/n4820022/LogRotator.png>

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



--
View this message in context: http://jenkins-ci.361315.n4.nabble.com/Unexpected-memory-footpring-from-LogRotator-tp4820022.html
Sent from the Jenkins dev mailing list archive at Nabble.com.