串行内存消耗并行内存_如何估算内存消耗？

串行内存消耗并行内存

这个故事可以追溯到至少十年之前，当时我第一次接触PHB时遇到一个问题：“在生产部署中，我们需要购买多大服务器”。我们正在构建的新的，闪亮的系统距离生产开始还有9个月的时间，显然该公司已承诺提供包括硬件在内的整个解决方案。

天哪，我有麻烦了。凭借几年的经验，我几乎可以掷骰子了。尽管我确信我完全缺乏信心是显而易见的，但我仍然不得不想出答案。四个小时的谷歌搜索之后，我想起坐在那里，同样的问题仍然徘徊在我眼花bed乱的脸前：

“如何估算对计算能力的需求？”

在本文中，我为您提供了有关如何估算全新Java应用程序的内存需求的粗略指导，从而开始了这一主题。对于不耐烦的用户，答案是从大约等于5 x [Live Data占用的内存量]的内存开始，然后从那里开始进行微调。对于那些对背后的逻辑更加好奇的人，请留在我身边，我将带您进行推理。

首先，我只能建议避免在没有详细信息的情况下回答这样的问题。您的答案必须基于性能要求，因此，即使没有先澄清这些要求也不要开始。我的意思不是太含糊的“系统需要支持700个并发用户”，而是考虑到数据量和使用模式而提出的有关延迟和吞吐量的更多具体说明。也不要忘记预算-我们所有人都可以梦到亚毫秒级的延迟，但是那些没有HFT银行骨干预算的人们-不幸的是，这只是一个梦想。

现在，假设您已具备这些要求。下一站将是创建模拟用户行为的负载测试脚本。如果现在可以同时启动这些脚本，那么您已经为答案奠定了基础。正如您可能已经猜到的那样，下一步涉及我们通常建议的不要猜测的建议。但是要注意。

实时数据大小

即，我们追求最佳内存配置需要捕获实时数据大小。捕获了这一点之后，我们就可以进行微调的基线配置了。

如何定义实时数据大小？ Charlie Hunt和Binu John在他们的“ Java Performance ”书中给出了以下定义：

实时数据大小是在稳定状态下运行应用程序所需的一组长期对象消耗的堆大小。

有了定义，我们准备在打开GC日志记录的情况下对应用程序运行负载测试（-XX：+ PrintGCTimeStamps -Xloggc：/tmp/gc.log -XX：+ PrintGCDetails），并可视化日志（使用例如gcviewer的帮助）来确定应用程序达到稳定状态的时间。您所追求的类似于以下内容：

规划能力

我们可以在熟悉的双锯齿图形中看到GC在次要GC和Full GC运行中都能完成工作。在第21秒运行第一个完整GC之后，该特定应用程序似乎已经达到稳定状态。但是，在大多数情况下，需要10到20个完整GC运行才能发现趋势变化。在运行了四个完整的GC之后，我们可以估计实时数据大小大约等于100MB。

前面提到的Java Performance书现在表明，在典型的Java EE应用程序中，“实时数据大小”与最佳内存配置参数之间存在很强的相关性。该领域的证据也支持他们的建议：

将最大堆大小设置为3-4 x [实时数据大小]

因此，对于当前的应用程序，我们应该将-Xmx设置为介于300m和400m之间，以进行初始性能测试，然后从那里开始进行测试。

我们对本书中的其他建议有不同的看法，建议将最大永久代大小设置为1.2-1.5 x [永久代的实时数据大小]，并将-XX：NewRatio设置为[[实时数据大小]。目前，我们正在收集更多数据以确定正相关性是否存在，但是在此之前，我建议您将生存和简化配置的决定基于监视分配率。

您现在可能会问为什么要打扰。的确，有两个原因不引起立即关注：

在撰写本文时，8G内存芯片的价格不到100美元
虚拟化，特别是在使用大型供应商（例如Amazon AWS）时，使调整容量变得容易

这两个原因都是部分有效的，并且肯定减少了精确配置的需求。但是他们两个仍然把你置于危险区域

当“以防万一”投入大量内存时，您很可能会显着影响延迟-进入8G以上的堆时，引入跨越数十秒的Full GC暂停非常容易。
当以“稍后再调整”的思想进行过度配置时，“后期”部分趋向于永不满足。正因为如此，我面对了许多在预置环境上运行的应用程序。例如，我发现在Amazon EC2 m1.xlarge实例上运行的上述应用程序使该公司每年每实例花费4,200美元。将其转换为m1.small可以使实例的账单减少到520美元。如果您的部署规模很大，则可以从您的运营预算中看到8倍的成本降低，请相信我。