|
||||||||
|
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/d/optout.
For us this problem seems to have improved a lot with Jenkins 1.563 and corresponding slave.jar 2.41 on the slaves.
It was just a try that we did as
JENKINS-22734seemed to be related and fixed in that version. Somehow we now do not see any more broken slave connections even on high load (on either master or slave).What we still need is to disable the Response Time and Clock Difference preventive monitoring on the nodes->configure page.
This is because we've noticed (even with 1.563) that right after launching Jenkins Master the Response Time (of all slaves) is recorded around 10000 ms (10 secs). Within the first few minutes after starting the Master the Response Time then slowly decreases to acceptable values of << 500 ms. But if preventive monitoring is on, the slaves are taken down due to the huge values at the beginning and before the Response Time decreases. Our LAN infrastructure is 1 GE connections on the slaves and a 10 GE on the Master (virtualized in a VMWare VM) with all machines directly connected to enterprise-grade backbone core switches of our data center. OS ping times are far below 1 ms.