【发布时间】：2015-04-25 23:57:36
【问题描述】：
我正在使用 Jmeter 向部署在 AWS EC2 实例上的应用程序注入工作负载。测试必须非常庞大：持续 10 小时，工作负载曲线呈双峰形状，5 分钟内大约有 2600 个请求。实际上，我有一个部署应用程序的 m3.xlarge 实例和 8 个 m3.xlarge 实例，每个实例都运行一个 jmeter 实例。使用 python 脚本，要注入的工作负载在 8 个客户端实例之间进行拆分，因此例如，如果原始工作负载要注入 800 个请求，则每个 jmeter 实例将注入 100 个请求。正如我所说的那样，完整的测试持续 10 个小时，并分为每个 5 分钟的时间步长。每 5 分钟应用一点工作负载变化。实际上，在测试开始并且没有请求到达应用程序后，我立即从每个 jmeter 实例中得到 java.lang.OutOfMemoryError: GC overhead limit exceeded 错误。我在网上和 stackoverflow 上阅读了很多内容，并得出结论可能的错误可能是：
-
JMV 堆大小太低-> 我解决了在每个 jmeter 实例的 jmeter.bat 文件中设置以下问题：
设置 HEAP=-Xms4g -Xmx4g
设置 NEW=-XX:NewSize=4g -XX:MaxNewSize=4g
代码中的一些错误会导致垃圾收集器继续无用地使用。所以我从我的测试中删除了所有的 jmeter 监听器。特别是我使用了 TableVisualizer、ViewResultsFullVisualizer、StatVisualizer 和 GraphVisualizer。
无论如何问题仍然存在。我真的不知道如何解决它。我知道 2600 音高请求的 10 小时测试可能是一个非常繁重的测试，但我认为应该有一种方法来执行此操作。我正在使用 EC2 m3.xlarge 实例，因此如果有用的话，我什至可以将堆大小提高到 8G，或者由于我使用的是 Spot 实例，所以将工作负载分配给更多的客户端，所以我不会支付这么多，但是因为我已经将客户端实例的数量从 4 增加到 8 以解决问题并且不起作用，所以我有点困惑，我想在继续获得越来越多的资源之前了解 r 建议。 非常感谢您。
【问题讨论】：
-
是的，JMeter 是一个臭名昭著的资源吞噬者。在测试会话进行时，一定要关闭所有累积数据的组件。尽你所能。
-
修改bot jmeter.bat中的HEAP和NEW参数设置为2/4/8g是否正确？
-
NEW参数看起来是错误的做法。如果您获得 OOME，则意味着保留了许多 old 对象，而这些NEW参数会强制 JVM 将所有内容视为新对象。这意味着 Minor GC 会非常慢。让 JVM 动态调整世代大小通常是最好的选择。 -
我怎样才能得到这个？我刚刚尝试设置以下内容： set HEAP=-Xms8g -Xmx8g set NEW=-XX:-UseGCOverheadLimit -XX:-UseGCOverheadLimit 但它不起作用。我知道测试持续 10 个小时，每个 jmeter 实例必须同时启动 300 个请求，但我想应该有办法做到这一点。
标签： java amazon-ec2 garbage-collection jvm jmeter