-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins ver. 2.184
Benchmark 1.0.9
Several days ago we've noticed that our Jenkins master had almost all its 12 core under 100% load. Apparently it's been that way for several days straight. Using Monitoring plugin we've figured out there was about 10 threads with tremendous amount of time spent in `java.util.TreeMap.put`. Killing those threads one by one didn't break anything, so we assumed it to be some strange jenkins quirk and went on. AFAIK stack traces weren't informative.
Today I noticed there are 3 threads each eating 100% of core again. This time stack traces are more informative (see attachments). I cannot confirm that those two issues with CPU load are directly correlated, but the current one seems legit enough.
Hi Artalus,
How big is the history of builds maintained for jobs?
When accessing the result page, the plugin loads the result files for all builds in a multithreaded fashion. At the time, it uses all available threads minus a few to maintain standard operations. This loading depending on the size of the history of builds can reduce CPU availability on the computer until loading is complete. It was implemented to speed load the result page. I could add an option to select the number of threads being used.
I am currently traveling but I can look into implementing the change next week. Otherwise, if you have the time, you can create your own custom branch and submit your proposed change.
Let me know,