Glassfish线程池问题

我们使用的是Glassfish 3.0.1，并且遇到很长的响应时间;对于我们的POST/PUT请求的25％，在响应返回时前端负载均衡器超时的时间为5分钟。Glassfish线程池问题

我的理论是请求排队等待可用线程。

我认为这是因为访问日志显示请求需要几秒钟才能完成，但请求正在执行的时间比我预期的要晚五分钟。

有没有人有任何建议调试线程池发生了什么？或者最适合他们的设置是什么？

是否需要定期执行线程转储或者一次性转储是否足够？

来源

2012-12-05 Louis Q

什么是您的工作者线程池大小？ – user85155

我们有两个线程池：http-thread-pool和\t线程池-1，后者用于EJB请求我相信，最小的大小是5，最大的是500，我如何找出工作线程池的大小？ –

乍一看，这似乎与线程本身很少有关。在不了解网络设置的其余部分的情况下，我会检查以下内容：

负载平衡器池中是否存在死/无响应节点？这可能导致所有请求都被尝试对该节点进行尝试，直到它们在重定向到其他节点之前由于超时而失败。
负载均衡器和Glassfish服务器之间的初始连接是否存在一些问题？这可能是缓慢或不正确的DNS查找（尽管服务器应缓存结果），缺少代理或其他与网络有关的问题。
您是否检查过机器之间的时钟是否同步？这可能会导致日志不同步。 5分钟是一个非常奇怪的超时时间。

如果所有这些都空了，您可能只是负载平衡器和Web服务器之间的阻抗不匹配，您可能需要添加Web服务器来处理负载。负载均衡器应该能够为您提供大量的流量统计数据以及它的堆叠情况。

来源

2012-12-26 17:12:55 saarp

考虑threaddump是调试线程池正在进行的最佳方法。请在每个线程转储之间以1-2秒的间隔依次进行3-4次线程转储。

在threaddump中，可以通过名称找到工作线程的数量。从多个线程转储中找出长时间运行的线程。

您可以使用TDA工具（http://java.net/projects/tda/downloads/download/tda-bin-2.2.zip）分析线程转储。

来源

2012-12-26 18:42:16 sky

如果您在服务器中配置的工作线程不足，通常会出现此问题。普通网络服务器中的默认值范围为15到100个线程。但是，如果您的应用程序阻塞了服务器的工作线程（例如通过等待查询），则默认值的频率太低。您可以将工作人员的数量增加到1000个（确保64位）。还要检查任何中间服务器（例如代理或通过mod_proxy的apache转发）的workerthread数（有时称为“最大并发/打开请求数”）。

另一个常见的错误是软件向自己发送请求（例如尝试重新路由或转发请求），同时阻止传入的请求。

来源

2012-12-26 20:59:36

Glassfish线程池问题

回答

相关问题