经过一段时间的繁重负载后,Java/jetty不响应连接

Question

我们的Java servlet在Jetty下运行时遇到了一个非常棘手的问题.当负载低至中等时,它可以很好地工作,但是当负载达到一定水平时,它将在大约10-20分钟后停止响应请求.

如果我们在使用curl连接到它时跟踪主java进程,我们可以看到它设置连接,接收请求,解析它并执行它通常做的事情(查询Solr服务器,执行一些MySQL查询等),但是结果永远不会发送回客户端.

当它挂起时,它会无限期地挂起.没有多少时间会使它"突然出现",但是如果我们杀死主java/jetty进程下的任何随机线程,则线程数会下降并且它会再次开始响应请求.

以下是它的外观:

# curl http://localhost:8080/some-servlet-url

(Does not respond at this point)

# ps -efL | grep qserv | wc -l
243
# ps -efL | grep qserv | wc -l
243
# ps -efL | grep qserv | wc -l
243

(Number of threads remain seemingly constant)

# kill 29760   <--- random thread under the main java/jetty process
# ps -efL | grep qserv | wc -l
26

(Number of threads immediately decreases sharply)

# curl http://localhost:8080/some-servlet-url
... HTTP response ...

(Responds to connections again)

该服务器是运行Ubuntu 12.04.1 LTS和Jetty 8.1.7.v20120910的m2.2xlarge Amazon EC2实例

$ java -version
java version "1.7.0_07"
OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

我们尝试了几种不同的java和Jetty版本.我们也尝试过使用Tomcat而不是Jetty - 同样的问题.

使用YourKit分析应用程序显示没有明显的线程锁定或过多的CPU使用率.

有任何想法吗？

编辑:我们能够得到挂起的java进程的堆栈跟踪,看起来所有的http线程都处于这种状态:

"http-bio-8080-exec-5" daemon prio=10 tid=0x00007fe518007800 nid=0x1fc5 in Object.wait() [0x00007fe57934f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076ee9d230> (a org.apache.commons.pool.impl.GenericObjectPool)
        at java.lang.Object.wait(Object.java:503)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:810)
        - locked <0x000000076ee9d230> (a org.apache.commons.pool.impl.GenericObjectPool)
        at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
        at net.acmecorp.active.QueryResultXMLFormatter.selectBestHitsAndRunDocumentCompletion(QueryResultXMLFormatter.java:362)
        at net.acmecorp.active.QueryResultXMLFormatter.queryResultToXMLRootElement(QueryResultXMLFormatter.java:167)
        at net.acmecorp.active.QueryPrepareAndExecuter.prepareParametersAndExecuteQuery_AndInvokeFormatter(QueryPrepareAndExecuter.java:239)
        at net.acmecorp.servlets.MultiQueryServlet.handle(MultiQueryServlet.java:470)
        at net.acmecorp.servlets.MultiQueryServlet.doGet(MultiQueryServlet.java:85)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
        - locked <0x0000000700dd70d0> (a org.apache.tomcat.util.net.SocketWrapper)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

   Locked ownable synchronizers:
        - <0x000000076ed40990> (a java.util.concurrent.ThreadPoolExecutor$Worker)

我自己并不是一个真正的java人,所以我无法确切地看到这里有什么问题,但看起来他们似乎都在等待......

Answer 1

您有数据库池问题，您的 http 线程都在等待数据库资源释放。这是一个常见问题，您要么需要增加池中的数据库连接数，这样就不再是问题，要么您需要使用像 jetty 中的 QoSFilter 这样的 QoS 服务来限制进来的请求数保护小型数据库池的进程。

现在，你的数据库池被消耗的原因可能有很多，你可能在应用程序中泄漏它们（从池中获取它们，使用它们，并且从不返回它们）或者你可能只是有太多的请求进来同时。或者是数据库池库本身的问题，它会发生。

无论哪种方式，这都不是码头或 tomcat 问题，而是您的应用程序和数据库之间的资源争用问题。请求进入 jetty 或 tomcat，进入 servlet 域，然后在 servlet 等中等待数据库连接，就这么简单。