10

我们使用的是 Glassfish 3.0.1，响应时间很长；对于 25% 的 POST/PUT 请求，大约需要 5 分钟，当响应返回时，前端负载均衡器已超时。

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

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

有人对调试线程池的情况有什么建议吗？或者他们的最佳设置应该是什么？

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

4

3 回答 3

6

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

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

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

于 2012-12-26T17:12:55.467 回答
3

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

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

于 2012-12-26T20:59:36.423 回答
2

使用 threaddump 是调试线程池的最佳方式。请一个接一个地进行 3-4 个线程转储，每个线程转储之间有 1-2 秒的间隙。

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

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

于 2012-12-26T18:42:16.233 回答