|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
I looked at the additional thread dumps vmassol-20130625*.txt and I think Jesse's earlier analysis still applies — they are showing that while the UI thread is stuck, it's busy loading records from the disk.
I see that three thread dumps involve two jobs "xwiki-platform Quality Checks" and "xwiki-platform". They are both Maven projects with lots of modules, so I can imagine that if the cache is cold, this can result in a considerable delay. When I access this instance, I experience that the first page load time of those two jobs are considerable, yet if I reload the page it renders quickly enough.
Between these and the perm gen problem, I suspect that JVM in question simplify doesn't have enough heap size to keep the cache warm enough. Again, I'd love to see the heap dump that I requested above to see if there's something wasting the heap.
Another thought that occurred to me is if it helps to provide an option to make the build records a strong reference, instead of the weak reference. It shifts the memory pressure from build records to other soft references, but for some users it might be an useful trade off.