-
Improvement
-
Resolution: Unresolved
-
Major
-
Jenkins ver. 1.565, global-build-stats: 1.3, Redhat 6, SAN fs with tiers (SSD, disk, ...)
We have problems with slow startup of Global Build Stats Plugin. We have an installation with ~1000 jobs and around 50 builds kept per job. Big, but nothing extreme.
Could this be due to some corrupted stats file that makes it read all builds of every job, or is it ALWAYS doing that at startup?
I've seen some bad interactions between plugins, e.g. template-project and jobConfigHistory. Where combined they cause ridiculous amount of work.
Excerpt from Jenkins logs.
With plugin:
INFO: Took 665401ms for item listener hudson.plugins.global_build_stats.GlobalBuildStatsPlugin$GlobalBuildStatsItemListener startup INFO: Took 718900ms for complete Jenkins startup
Without plugin:
INFO: Took 57859ms for complete Jenkins startup
The plugin is from a time when Jenkins loaded all data into memory on startup. Now build records are retained as soft references and only loaded on demand. There's a chance you can make it better by adding more RAM/Xmx, but it's possible the plugin just doesn't work well with Jenkins 1.485+.
Re JobConfigHistory, disable deduplication in the global options. It's expensive.