如何通过负载测试优化JVM和GC
编辑：在这个问题已经收到的几个非常慷慨和有帮助的回答中，很明显，当我今天早上问这个问题的时候，我并没有把这个问题的一个重要部分说清楚。到目前为止，我得到的答案更多是关于优化应用程序&在代码级别消除瓶颈。我知道这比尝试从JVM中获得额外的3%或5%更重要！
这个问题假设我们已经尽了一切努力在代码级别优化我们的应用程序架构。现在我们需要更多的内容，下一个要查看的是JVM级别和垃圾收集；我已经相应地更改了问题标题。再次感谢！
我们有一个“管道”风格的后端架构，其中消息从一个组件传递到另一个组件，每个组件在每一步执行不同的进程。
组件位于部署在Tomcat服务器上的WAR文件中。我们总共有大约20个组件在管道中，生活在5个不同的Tomcat服务器上(我没有为每个服务器选择WAR的体系结构或分布)。我们使用Apache来创建组件之间的所有路由，有效地形成管道的“结缔组织”。
我被要求优化运行JVM的每个服务器的GC和一般性能(总共5)。我花了几天时间阅读GC和性能调优，并且很好地处理了每个不同的JVM选项做什么，堆是如何组织的，以及大多数选项如何影响JVM的总体性能。
我的想法是，优化每个JVM的最佳方法不是将其作为一个独立的优化。我“感觉”(这就是我所能证明的！)试图在本地优化每个JVM，而不考虑它将如何在其他服务器(上游和下游)上与其他JVM交互，这不会产生一个全局优化的解决方案。
对我来说，优化整个管道作为一个整体是有意义的。所以我的第一个问题是：同意，如果不是，为什么？
为此，我考虑创建一个LoadTester，它将生成输入并将其输入到管道中的第一个端点。这个LoadTester还可能有一个单独的“监视线程”，它将检查最后一个端点的吞吐量。然后，我可以进行各种处理，检查消息的平均端到端旅行时间、故障前的最大吞吐量等。
LoadTester将一次又一次地生成相同的输入消息模式。本实验中的变量是传递给每个Tomcat服务器的启动选项的JVM选项。我列出了大约20个不同的选项，我想通过JVM，并认为我可以继续调整他们的值，直到我找到了接近最佳的性能。
这可能不是绝对最好的方式，但这是最好的方式，我可以设计的时间，我已经为这个项目(约一周)。
第二个问题：是怎么看待这个设置的？那么如何创建一个“优化解决方案”呢？
最后但并非最不重要的一点是，我想知道我可以使用什么样的度量作为度量和比较的基础。我真的只能想到：
JVM选项配置可以为messages
- Find生成最快的平均端到端旅行时间，JVM选项配置可以产生最大的卷吞吐量而不会使任何服务器
崩溃。
还有其他人吗？为什么那两个是坏的？
在回顾了剧本之后，我可以看到这可能被解释为一个单一的问题，但我真正想问的是，这样如何才能优化运行在管道上的JVM，并且可以随意裁剪我的解决方案，不管你喜欢它。
提前感谢！
回答 3
Stack Overflow用户
发布于 2012-01-05 17:15:01
让我提升一个级别，说我在很多年前在一个大型C应用程序中做了类似的事情。它由多个进程组成，通过相互连接的硬件交换消息。我想出了一个两步的方法。
步骤1.在每个过程中，我使用this technique来消除任何浪费的活动。这需要几天的取样、修改代码和重复。这个想法是有一条链的，首先要做的是消除链接中的无效。
第二步，这个部分很费劲，但很有效:生成有时间戳的消息流量日志。将它们合并成一个共同的时间表。仔细查看特定的消息序列。你要找的是
- 是必要的消息，还是由于超时或其他可避免的原因而产生的重传？
- 何时发送、接收和执行消息？如果在收到和采取行动之间有很大的延误，那么这种拖延的原因是什么？例如，这仅仅是“排在另一个正在执行I/O的进程后面”的问题吗？它是否有不同的进程优先级？
这个活动花了我大约一天的时间来生成日志，组合它们，找到加速的机会，并修改代码。以这种速度，在大约10个工作日后，我发现/修复了一些问题，并大大提高了速度。
这两个步骤的常见之处在于，我没有测量或试图获取“统计数据”。如果某件事情花费了太多的时间，那么这个事实就会暴露给一个扩张的程序员，仔细观察正在发生的事情。
Stack Overflow用户
发布于 2012-01-05 16:27:56
首先，我将找到为您的硬件/软件组合指定的最佳推荐jvm值，或者从已经存在的jvm开始。
接下来，我将确保我有适当的监视，以测量业务吞吐量和SLA
如果没有理由，我不会试图调整GC。
首先，您需要找到应用程序中的主要瓶颈。如果是I/O绑定、SQL绑定等。
这里的关键是测量、识别顶级瓶颈、修复瓶颈并使用可重复的负载进行另一次迭代。
嗯..。
Stack Overflow用户
发布于 2012-01-05 17:07:57
当在同一台机器上运行多个JVM时，我知道的最大的窍门是限制GC将使用的核心数量。否则，当一个JVM完成一个完整的GC时，它会尝试抓取每个核心，影响所有JVM的性能，即使它们没有执行GC。一种建议是将gc线程的数量限制在5/8或更少。(我不记得它写在哪里了)
我认为您应该对整个系统进行测试，以确保服务之间有实际的交互。但是，我假设您可能需要对每个服务进行不同的调优。
如果无法更改代码，则更改命令行选项非常有用。但是，如果您分析并优化了代码，那么除了调优GC参数之外，您还可以做出更大的改变(在这种情况下，您需要再次更改它们)。
由于这个原因，我只会作为最后手段更改命令行参数，因为在应用程序的代码中几乎没有什么改进。
https://stackoverflow.com/questions/8745695
复制相似问题
腾讯云开发者
