Glassfish线程池问题

Question

我们正在使用Glassfish 3.0.1，并且经历了很长的响应时间;对于25％的POST / PUT请求，大约5分钟，当响应返回时，前置负载均衡器已经超时。

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

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

有没有人对调试线程池的内容有任何建议？或者他们的最佳设置是什么？

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

Answer 1

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

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

如果所有这些都是空的，您可能只是在负载均衡器和Web服务器之间存在阻抗不匹配，您可能需要添加Web服务器来处理负载。负载均衡器应该能够为您提供大量关于流量的统计信息以及它的堆叠方式。

Answer 2

如果您在服务器中配置的工作线程不够，通常会出现此行为。普通Web服务器中的默认值范围为15到100个线程。但是，如果您的应用程序阻止服务器的工作线程（例如，通过等待查询），则默认值太低。 您可以毫无问题地将工作人员数量增加到1000（确保64位）。还要检查任何中间服务器（例如代理或通过mod_proxy转发的apache）的workerthreads数量（有时称为“max concurrent / open requests”）。

另一个常见的缺陷是您的软件在阻止传入请求时向自身发送请求（例如，尝试重新路由或转发请求）。

Answer 3

使用threaddump是调试线程池的最佳方法。请一个接一个地使用3-4个螺旋减速器，每个螺纹减速器之间有1-2秒的间隙。

从threaddump中，您可以按名称查找工作线程数。从多个threaddumps中找出长时间运行的线程。

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