<div dir="ltr">I've played a bit with datadog and now eggplant (jira&confluence) is monitored through datadog with pagerduty integration, and I like it.<div><br></div><div>There are really only just two servers that we want to monitor --- cucumber & eggplant, and that just costs $30/month. I think it's a good use of our money to help the infra work. Any thoughts?</div><div><br></div><div>If anyone else wants to see the dashboard, I can add you to the "Jenkins" org.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-23 19:03 GMT-07:00 Kohsuke Kawaguchi <span dir="ltr"><<a href="mailto:kk@kohsuke.org" target="_blank">kk@kohsuke.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">A related problem here is that when lettuce was moved from old puppet management to new puppet management, it must have been reinstalled from scratch. And we lost nagios during this transition --- try hitting <a href="http://nagios.jenkins-ci.org/" target="_blank">http://nagios.jenkins-ci.org/</a> and you'll see it yourself.<div><br></div><div>So we are flying blind when it comes to monitoring, which means when a Confluence issue like this happens, we don't get to notice.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-23 18:59 GMT-07:00 Kohsuke Kawaguchi <span dir="ltr"><<a href="mailto:kk@kohsuke.org" target="_blank">kk@kohsuke.org</a>></span>:<div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As I was about to issue a security advisory, I've noticed that Confluence is acting up. It accepts inbound HTTP connections, but very slowly, and then even if it accepts connections, it fails to render HTML in a timely manner.<div><br></div><div>Now I think I know what's going on.</div><div><br></div><div>The way the system is put together is that there's Apache at the very front, and requests for wiki is forwarded to nginx that acts as the cache layer. If a cache fails, nginx further forwards the request to Tomcat, which runs Confluence.</div><div><br></div><div>I think the root cause of the problem is that /srv/wiki/cache weren't fully populated. I've discovered this at the very end, and I still don't know why this was only partially populated, but this explains everything.</div><div><br></div><div>Normally, the cache tier responds to most requests. But now that the cahe is gone, Confluence takes far more load than usual. Unfortunately, Tomcat was configured to spin up to 200 request handling threads, yet it only had 15 DB connections in the pool. So almost all of 200 request handling threads all ended up competing for available database connections. This was quite visible in the thread dump.</div><div><br></div><div>I've made the change to double the DB connecton pool size to 30 as per <a href="https://confluence.atlassian.com/display/CONFKB/Confluence+Slows+and+Times+Out+During+Periods+of+High+Load+Due+to+DB+Connection+Pool" target="_blank">this KB document</a> (which had to be be done outside Puppet as this file contains passwords and so cannot be managed in infra-puppet), and reduced the # of maximum request handling threads from 200 to 75. In this way, even if Confluence sees increased load, it doesn't end up taking too many connections that it cannot serve.</div><div><br></div><div>I've also issued re-generation of static cache. Confluence CPU usage is down and the site is mostly snappy, and it'll get better as the static cache fills up.</div><span><font color="#888888"><div><br clear="all"><div><br></div>-- <br><div>Kohsuke Kawaguchi</div>
</div></font></span></div>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Kohsuke Kawaguchi</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Kohsuke Kawaguchi</div>
</div>