我们的生产用户每月至少抱怨两到三次性能问题。我们有生产中的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
我们正在考虑增加堆大小。但是,在执行此操作之前,我们应该从服务器收集哪些性能参数以缩小问题的根本原因
答案 0 :(得分:3)
第一步,您应始终监视基础系统(硬件服务器,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%的可用权空间运行,则需要增加堆大小或将一些工作负载移出服务器。