群集生产服务器中的性能问题

Question

我们的生产用户每月至少抱怨两到三次性能问题。 我们有生产中的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

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

Answer 1

第一步，您应始终监视基础系统（硬件服务器，VM，容器）的关键性能资源-CPU利用率，可用内存，网络使用情况等。如果您的设备用完了CPU周期或可用RAM，则应用服务器性能会受到影响。

下一步，Java和WAS提供了各种性能指标，可以帮助诊断像您这样的问题。 WAS性能调查的有用指南是《 WebSphere Application Server性能手册》 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％的可用权空间运行，则需要增加堆大小或将某些工作负载移出服务器。