我们还没有遇到任何应用程序错误，但我们的监控工具表明，我们的应用程序正在运行的资源的限制。 我们应该先添加更多的堆还是添加额外的VM？
我们有一个应用程序在托pipe集群中的WebLogic / JRockit上运行。
我们有AppDynamics监控这个应用程序，它显示主要垃圾收集频繁发生（平均每1-2分钟!!!）。 当一个主要垃圾收集运行时，它确实会恢复空间，即使在系统启动一段时间（几个星期/几个月）之后，堆的使用范围也会相当低。 另外，我们运行了AppDynamics集合泄漏检测产品，发现没有泄漏。 （我们无法运行自定义监视，因为它不受JRockit支持。）但是总的来说，似乎很清楚，没有大的泄漏，只是系统需要比目前更多的资源。
我们有两个非生产环境也运行这个应用程序，减less资源和减less负载（开发和testing）。 testing环境具有2/3的虚拟机数量和每个虚拟机的1/2堆。 我们对这个环境进行了一些负载testing，但结果并不是很有帮助。 虽然我们可以使用自动化脚本来重新创build用户数量，但我们的testing环境中的数据是非常不同的 – 查询返回的数据量要less得多，等等（创build一个更好的负载testing环境当然是在ToDo列表上，但不太可能由于官僚主义的原因，很快就会发生。）即使我们可以投入的一切，testing环境也没有出汗。
两个选项，A）添加更多的堆。 看来这样做肯定会有所帮助，但完成这项工作将需要大量的文书工作（需要向物理服务器添加更多内存，这意味着服务器重新启动涉及大量其他应用程序等）。 此外，我不知道要增加多less内存，我们不能只是“testing”。 B）为这个应用程序添加另一个VM（或两个）。 这将是相当容易的，我们在另一台物理服务器上有空间，所以我们可以很快完成。 但是我不确定这会有多大帮助，如果没有帮助，那么稍后再回到选项A就更难了。
具体问题：1）上述哪一个选项显然更好（以及为什么）？ 2）如果两者都没有明显好转，我会做什么testing等等来决定哪个更好？ 3）我应该如何决定和certificate需要添加多less资源（堆或虚拟机）？ （如果涉及到我们已有的工具，可以在这里获得奖励）
更新：
假设应用程序已经被彻底地分析过，并且没有内存泄漏（就好像是这种情况），但是你必须在这样的前提下工作：在堆中创build的对象是由应用程序的正常活动引起的。
根据所创build对象的大小和生命周期（这又取决于您使用的特定JVM），避免代码优化和/或内存堆更加精细的调整，除了增加更多内容外，没有太大的改进空间托pipe节点到您的域。
这可以通过使用每个WebLogic安装中已经存在的工具（即WLST）轻松实现。
有关如何使用WLST将受pipe节点及其各自的节点pipe理器创build到现有集群的文档很好。
我们最终做了两个（从1GB增加更多的堆空间到1.5GB，并添加更多的pipe理节点从3个节点到5）。
在新节点添加之前，堆增加了大约一个小时，本身足以显着减less垃圾收集数量和垃圾收集时间。
增加更多的节点只会带来一些小的改进，但是很难确定它是否真的没有什么帮助，或者增加堆后没有太多的改进空间。