Memory was way below max for us too.
From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Scott Evans Sent: Thursday, January 17, 2013 9:39 AM To: jenkinsci-users@googlegroups.com Subject: Re: Slow Jenkins response to http after upgrade Check to make sure your java memory settings didn't get set too low during the upgrade, as we had issues with slow reponses at times which cleared up once we configured the Jenkins java process to have more memory available than the default. I believe this setting can be configured in jenkins.xml. Scott On Thu, Jan 17, 2013 at 11:10 AM, Richard J <r...@columbia.edu> wrote: We also have the same scenario- upgrade from last LTS to 1.480.1 on windows 7-64. In the last 3 weeks since the upgrade, the Jenkins server has three times "hung" in terms of its response to web browers. The first time, the server responded to browser after 30 second delays,and started to respond normally again after about 15 minutes. The second and third time, I gave up waiting and had to restart Jenkins. I didn't see any exceptions in the log that corresponded to the pronlems. On Thursday, January 17, 2013 12:51:18 AM UTC-8, Yitzhak Zuriel wrote: We recently upgraded our Jenkins CI servers to the latest LTS version (4.480.1 -- before this we were using version 4.447.2) After this upgrade, we found that on our busiest servers (especially on a master of 8 slaves; all run on Windows Server 2008 r2) that the http response becomes very slow. It's inconsistent, but approximately half of the time the GUI responds either sluggishly or seems stuck. Has anyone experienced this? Does anyone have suggestions for how we can investigate the cause of this? We thought it might be due to intensive SCM polling activity of many projects' commit jobs, so we increased the polling intervals and spread them out more, and this had no effect. I'd appreciate any ideas. A small related question: one of the things we want to do for our investigation is to record logs of http activity. Which logger name(s) should we use to capture such logs?
