0

我们的生产用户每月至少抱怨两到三次性能问题。我们在生产中拥有 IBM WAS 8 服务器。该应用程序使用两个基于 SOAP 的服务，例如 H 和 T。H 部署在 INTERNET 集群服务器（X、Y）上。T 部署在 INTRANET 服务器（U、V）上。客户端直接连接到 H。H 连接到 INTRANET 上的 T。基于 SOAP 的服务 H,T 都连接到数据库。此外，还有一项用于验证用户的服务。我们在服务器 U 和 V 的日志中没有看到任何错误。但是服务器 X、Y 上的 H 的日志给出了以下错误。不同时间的不同错误：

1. java.net.SocketTimeoutException: Socket operation timed out before it could be completed
2. java.io.IOException: Connection close: Read failed.  Possible end of stream encountered.  
java.lang.OutOfMemoryError: GC overhead limit exceeded
3. Exception - User fault processing is not supported. The @WebFault faultbean is missing for java.rmi.RemoteException
4. Authentication failed

我们正在考虑增加堆大小。但是，在这样做之前，我们应该从服务器收集哪些性能参数以缩小问题的根本原因

4

1 回答 1

3

作为第一步，您应该始终监控底层系统（硬件服务器、VM、容器）的关键性能资源——CPU 利用率、可用内存、网络使用情况等。如果您的机器耗尽 CPU 周期或可用 RAM，则应用服务器性能会受到影响。

作为下一层，Java 和 WAS 提供了各种性能指标，可以帮助诊断像您这样的问题。WAS 性能调查的有用指南是 WebSphere Application Server Performance Cookbook https://publib.boulder.ibm.com/httpserv/cookbook/
在您的情况下，这部分可能最适用： https://publib.boulder.ibm。 com/httpserv/cookbook/Recipes-WAS_Traditional_Recipes-General_WAS_Traditional_Performance_Problem.html

您列表中的错误之一是由于“超出 GC 开销限制”而引发的 OOM。这意味着服务器 JVM 在 Java 堆中的可用空间严重不足，因此它几乎所有时间都在运行 Java 垃圾收集，试图释放空间来做真正的工作。此类问题可能会导致您列出的其他问题，例如超时和通信失败。

要诊断过多的 GC 问题，您需要详细的 GC 日志记录 - 启用详细 GC 是上面第二个链接中的第 2 步，也在http://www-01.ibm.com/support/docview.wss?uid=swg21114927中进行了说明 详细 GC 日志记录的开销非常低，并且具有非常高的诊断价值，因此应该始终启用它，包括在生产环境中。

GC 日志中最关键的信息是每次全局 GC 后有多少可用的空闲任期堆。这应该至少是总任期堆大小的 30%，否则 JVM 将不得不做太多的 GC 工作来为您希望服务器执行的“实际工作”腾出空间。当繁忙的服务器上的可用任期空间少于 10% 时，通常会在配置中出现“超出 GC 开销限制”错误。

如果服务器在全局 GC 后始终以低于 30% 的可用使用期限空间运行，则您需要增加堆大小或将一些工作负载转移到服务器之外。

于 2019-02-05T18:20:57.600 回答