我司生产的用户抱怨的性能问题，每月至少有两到三次。我们IBM在生产8台服务器。该应用程序使用两个基于SOAP的服务说H和T. H被部署在INTERNET群集服务器（X，Y）。 T被部署INTRANET服务器上（U，V）。客户端直接连接到H H将上INTRANET吨。无论是基于SOAP的服务H，T连接到数据库。此外，还有用于验证用户身份的服务。我们并没有看到在服务器U和V的日志，但对服务器x高日志中的任何错误，Y给出以下错误。不同的错误在不同的时间：
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
我们正在考虑增加堆的大小。但是，在做之前什么性能参数，我们应该从服务器收集到缩小问题的根本原因
作为第一步，你应该随时监控底层系统（硬件服务器，虚拟机，集装箱），关键绩效资源 - 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工作，以明确空间。在“GC开销超限”错误通常出现在CONFIGS时，有一个繁忙的服务器上少于10％的可用空间任期。
如果一台服务器在全球GC之后不到30％的自由空间任期一致运行，或者需要增加堆大小或转移部分工作负载从服务器上。