-
Bug
-
Resolution: Fixed
-
Major
-
_unsorted, (26)
active-directory-plugin, backup-plugin, build-publisher-plugin, copy-to-slave-plugin, core, disk-usage-plugin, email-ext-plugin, emotional-hudson-plugin, googleanalytics-plugin, greenballs-plugin, locks-and-latches-plugin, msbuild-plugin, mstest-plugin, nant-plugin, ncover-plugin, nunit-plugin, parameterized-trigger-plugin, plugin-proposals, pmd-plugin, remoting, subversion-plugin, svn-tag-plugin, trayapp, violations-plugin, warnings-plugin, xunit-plugin -
None
Running latest version of Hudson in master-slave configuration on 2 servers, each with 4 CPUs with 1GB of memory, with each slave and the master assigned to an individual CPU. Using Subversion as Source Management and polling every 5 mins for changes. All projects in same repository target. Forcing Update and Revert because we have had issues with projects failing compilation step due to conflicts. SMTP mail functionality with editable e-mail notification. Have a few specific jobs tied to specific executor, allow others to free float to whatever executor is available. Locks & Latches to prevent concurrent execution of processes that should not run at same time. Using active directory to manage security. Reporting violations for FxCop, Simian, and JSLint (through PDM option).
Every 3 days or so we see the Master begin consuming 25% of the CPU power (even when nothing is running, the UI becomes slow and slows down as time goes by, and within a few hours the UI for the tool simply stops responding. We are forced to restart the service for the master to correct the issue. Remain unable to ascertain what is causing the issue, although we suspect based on research that it might be something with the Subversion polling mechanism.
[JENKINS-6406] Forced to restart Hudson Master every 3 days or so because process locks up.
ashlux
added a comment - Most likely you're seeing the master consuming CPU because the GC is running too frequently. Try increasing the amount of memory you give the master; I've noticed the master needs a decent amount if you have a lot of projects (we have around 70 projects and allocate 1.5 GB). You can use VirtualVM or some other profiling tools to verify that the GC is running frequently.
If that doesn't fix the issue use jstack to track down where Hudson might be spinning its wheels; though almost certainly it's spending too much time garbage collecting.
ashlux
added a comment - Most likely you're seeing the master consuming CPU because the GC is running too frequently. Try increasing the amount of memory you give the master; I've noticed the master needs a decent amount if you have a lot of projects (we have around 70 projects and allocate 1.5 GB). You can use VirtualVM or some other profiling tools to verify that the GC is running frequently.
If that doesn't fix the issue use jstack to track down where Hudson might be spinning its wheels; though almost certainly it's spending too much time garbage collecting. Any progress on this issue? Let us know if the above advice, or any recent upgrades, have helped. Thanks.
alexlombardi
added a comment - Not seeing this problem anymore in the latest releases. 
As a workaround, you could try a post-commit hook in your svn repository to trigger jobs instead of polling (see wiki page for subversion plugin).