如何通过负载测试优化 JVM & GC答案

【问题标题】：How to Optimize JVM & GC through Load Testing如何通过负载测试优化 JVM & GC
【发布时间】：2012-02-03 11:10:52
【问题描述】：

编辑：在这个问题已经收到的几个非常慷慨和有用的回答中，很明显，当我早些时候问这个问题时，我没有明确说明这个问题的重要部分早晨。到目前为止，我收到的答案更多是关于优化应用程序和消除代码级别的瓶颈。我知道这比试图从 JVM 中获得额外的 3% 或 5% 更重要！

这个问题假设我们已经做了几乎所有可以在代码级别优化我们的应用程序架构的工作。现在我们想要更多，接下来要看的地方是JVM级别和垃圾收集；我已经相应地更改了问题标题。再次感谢！

我们有一个“管道”风格的后端架构，其中消息从一个组件传递到下一个组件，每个组件在每一步执行不同的流程。

组件位于部署在 Tomcat 服务器上的 WAR 文件中。我们总共有大约 20 个组件在流水线中，存在于 5 个不同的 Tomcat 服务器上（我没有为每个服务器选择架构或 WAR 分布）。我们使用 Apache Camel 来创建组件之间的所有路由，有效地形成了管道的“结缔组织”。

有人要求我优化运行 JVM（总共 5 个）的每台服务器的 GC 和一般性能。我花了几天时间阅读 GC 和性能调优，并且很好地掌握了每个不同的 JVM 选项的作用、堆的组织方式以及大多数选项如何影响 JVM 的整体性能.

我的想法是优化每个 JVM 的最佳方法是不将其作为独立的进行优化。我“感觉”（就我所能证明的而言！）试图在本地优化每个 JVM 而不考虑它将如何与其他服务器（上游和下游）上的其他 JVM 交互不会产生全局优化的解决方案.

对我来说，将整个管道作为一个整体进行优化是有意义的。所以我的第一个问题是：是否同意，如果不同意，为什么？

为此，我正在考虑创建一个LoadTester，它会生成输入并将其提供给管道中的第一个端点。这个LoadTester 也可能有一个单独的“Monitor Thread”来检查最后一个端点的吞吐量。然后我可以进行各种处理，检查消息的平均端到端传输时间、故障前的最大吞吐量等。

LoadTester 会一遍又一遍地生成相同模式的输入消息。本实验中的变量将是传递给每个 Tomcat 服务器启动选项的 JVM 选项。我有一个大约 20 种不同选项的列表，我想通过 JVM，并认为我可以不断调整它们的值，直到找到接近最佳的性能。

这可能不是做到这一点的绝对最佳方式，但它是我在给这个项目的时间（大约一周）内可以设计的最佳方式。

第二个问题：SO 对此设置有何看法？ SO 如何以不同的方式创建“优化解决方案”？

最后但同样重要的是，我很好奇我可以使用什么样的指标作为衡量和比较的基础。我真的只能想到：

还有其他人吗？这两个不好的原因有什么？

在查看剧本后，我可以看到这可能会被解释为一个单一的问题，但我真正要问的是 SO 如何优化沿管道运行的 JVM，并随意切割我的解决方案不管你喜欢它。

提前致谢！

【问题讨论】：

请注意，即使在同一台计算机上运行完全相同的代码、相同的输入和相同的 JVM 参数，也可能会产生截然不同的结果（我在微基准测试中看到了 30% 的差异！）。不过，对于 c++ 应用程序也是如此（即ld *.o 可能比ld a.o b.o 快一点，反之亦然）。取决于您的应用程序有多大，这可能不是问题，但请确保您获得可重现的结果，即多次运行相同的 VM 选项，最终不仅会产生均值，还会产生方差！

【解决方案1】：

让我更上一层楼，说我多年前在一个大型 C 应用程序中做过类似的事情。它由许多跨互连硬件交换消息的进程组成。我想出了一个两步走的方法。

步骤 1. 在每个流程中，我使用this technique 来消除任何浪费的活动。这需要几天的采样、修改代码和重复。这个想法是有一个链条，首先要做的是消除链接中的低效率。

第 2 步。这部分费力但有效：生成带有时间戳的消息流量日志。将它们合并成一个共同的时间线。仔细查看特定的消息序列。你要找的是

消息是必要的，还是由于超时或其他可避免的原因而重新传输？
消息是何时发送、接收和执行的？如果在收到和采取行动之间存在显着延迟，那么延迟的原因是什么？例如，是否只是在另一个正在执行 I/O 的进程后面“排队”？是否可以通过不同的流程优先级进行修复？

这个活动花了我大约一天的时间来生成日志、合并它们、找到加速机会并修改代码。以这个速度，大约 10 个工作日后，我发现/修复了许多问题，并显着提高了速度。

这两个步骤的共同点是我没有测量或试图获得“统计数据”。如果某件事花费了太多时间，那么这个事实就会让勤奋的程序员仔细观察正在发生的事情。

【讨论】：

【解决方案2】：

我知道在同一台机器上运行多个 JVM 时最大的技巧是限制 GC 将使用的核心数量。否则，当一个 JVM 执行完整 GC 时可能发生的情况是，它会尝试抓取每个内核，从而影响所有 JVM 的性能，即使它们没有执行 GC。一种建议是将 gc 线程的数量限制为 5/8 或更少。（不记得写在哪里了）

我认为您应该对系统进行整体测试，以确保您在服务之间进行真实的交互。但是，我认为您可能需要对每项服务进行不同的调整。

如果您无法更改代码，则更改命令行选项很有用。但是，如果您分析和优化代码，您可以比调整 GC 参数（导致您需要再次更改它们）产生很大的不同

出于这个原因，我只会在万不得已的情况下更改命令行参数，在您之后，应用程序的代码几乎没有什么可以改进的地方。

【讨论】：

【解决方案3】：

我会从寻找为您的硬件/软件组合指定的最佳推荐 jvm 值开始，或者从已经存在的开始。

接下来，我将确保我有监控以衡量业务吞吐量和 SLA

如果没有理由，我不会尝试只调整 GC。

首先，您需要找出应用程序中的主要瓶颈。如果是 I/O 绑定、SQL 绑定等。

这里的关键是测量、识别 TOP 瓶颈、修复它们并使用可重复的负载进行另一次迭代。

HTH...

【讨论】：

谢谢，非常感谢您的意见。开箱即用的 GC 是线性的，这对于我们想要的不是最理想的 - 我们需要吞吐量 GC，它将是多线程的，以与服务器 CPU 一致。我当然会将我找到的最佳（“最佳”）配置与开箱即用的配置进行比较，但我相信我可以为我们找到更好的吞吐量。管道受内存限制，但我们有很大的 RAM，并且大量使用缓存，所以我不太担心瓶颈。