-
Bug
-
Resolution: Fixed
-
Major
If you have configured LogRotator to delete all builds older than 30 days, yet you do around 1000 builds a day, then at the end of each build LogRotator.perform will scan backwards from the previous build all the way to the first build (or nearby), loading each build along the way, just to find the (on average) one build which is now older than 30 days so it can be deleted. This forces thousands of builds to be kept in memory, or if they cannot all be held in memory, forces each build to reload thousands of older build records that it does not really need.
Would be better to do a binary search through the build history to find the newest build which is suitable for deletion.
Fixing this when numToKeep is set looks impractical, since AbstractLazyLoadRunMap.idOnDisk is not exposed (not even its size), and so there is no way of knowing which build is the 30000th oldest—you cannot rely on this having a particular build number. Fixing it for daysToKeep looks easier since you can simply browse forward from the oldest build and keep on deleting them so long as they are sufficiently old.