<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">3) The process was using 100% of CPU and taking up 126MB. The number of active connections was less than 10. It sits behind LVS which checks for connection uptime periodically which is why the high connection count.</SPAN></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Incidentally, an strace on the djabberd process shows a zillion:</DIV><BR><DIV>epoll_wait(9, {{EPOLLIN, {u32=13, u64=13}}}, 1000, -1) = 1</DIV><DIV>epoll_wait(9, {{EPOLLIN, {u32=13, u64=13}}}, 1000, -1) = 1</DIV><DIV>epoll_wait(9, {{EPOLLIN, {u32=13, u64=13}}}, 1000, -1) = 1</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I wonder if the watch_read or watch_write is getting messed up when LVS does a connect and then disconnect on the SSL port? It seems to build over time and the watch on/off with SSL looks tricky. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV></DIV><BR></BODY></HTML>