河北省唐山市建设规划局的网站,一个虚拟主机可以放几个网站,wordpress怎么设置title,apicloud成品源码java vm正如您从我们以前的面向性能的文章中可能已经看到的那样#xff0c;运行良好的JVM是实现最佳应用程序性能和稳定性的最重要目标之一。 这样的健康评估通常仅关注主要收集的频率#xff08;避免#xff09;或检测内存泄漏的存在。 年轻一代空间或短寿命物体的大小和足… java vm 正如您从我们以前的面向性能的文章中可能已经看到的那样运行良好的JVM是实现最佳应用程序性能和稳定性的最重要目标之一。 这样的健康评估通常仅关注主要收集的频率避免或检测内存泄漏的存在。 年轻一代空间或短寿命物体的大小和足迹如何 本文基于一个真实的故事和我们与一位IT客户的最新故障排除经验。 它将通过一个示例应用程序证明过多的内存占用空间和次要收集的频率可能会引发性能问题就像其老兄旧一代或使用期限的空间一样严重。 JVM健康状况诊断 如果您不熟悉JVM调优领域那么您很快就会意识到没有适用于所有应用程序的通用解决方案。 无论您可以从各种来源从Web上找到高质量的材料您都仍然需要进行尽职调查并正确了解要处理的应用程序类型包括其对JVM GC暂停的敏感性某些应用程序需要较低的JVM暂停时间1。 Java性能分析包括内存泄漏检测以及性能和负载测试是为收集所有正确数据以及有关应用程序内存占用量和JVM运行时运行状况的事实而需要执行的额外工作的良好示例。 话虽这么说“健康的” JVM是什么意思 请尽您所能回答以下问题。 **如果回答“否”请假设置信度为90否则回答“我不知道”。 您的Java堆或OldGen空间是否随着时间的流逝而泄漏在进行重大收集之后 您的应用程序当前是否受到大型和/或频繁的JVM GC暂停的影响 JVM的总体暂停时间是否高于5或高于已建立的理想基准 当前您的应用程序响应时间是否经常受到JVM GC活动的定期影响并且超出了应用程序的承受能力 在最近3个月中您是否观察到java.lang.OutOfMemoryError错误的发生 您是否在最近3个月内观察到JVM崩溃的发生带有核心转储和崩溃报告的JVM突然故障 您是否认为您的JVM当前不稳定并且/或者需要过多的人工干预定期重启等 如果您回答“是”或“我不知道”这意味着您或您的生产性能调整团队可以在这里做一些工作包括查看当前的JVM GC策略。 如果您对所有具有高置信度级别的用户回答“否”则意味着您可能已经获得了可靠的应用程序和JVM稳定性祝贺您。 我仍然建议您在主要版本和增量负载预测之间重新评估情况。 青年一代真的停止世界吗 正如我们从快速的JVM健康状况评估练习中看到的那样要点之一是指JVM的总体暂停时间。 这实质上意味着JVM在“停止世界”事件中花费了多少时间。 在此期间应用程序线程将被挂起并且不执行任何工作从而增加了应用程序的响应时间。 该指标至关重要因为较大的JVM暂停将触发不稳定且不可预测的响应时间。 我在过去几年中看到的一个普遍误解是YoungGen或次要集合是完全透明的并且不会影响应用程序的响应时间。 如果您的Java堆大小较小YG空间1 GB并且处理的对象生存期或分配率适中则此语句几乎是正确的。 在这种情况下如果次要集合执行得非常快20 ms并且执行得不太频繁每30秒以上则YoungGen空间贡献的JVM总体暂停时间将保持很小 1。 但是如果YG内存分配率提高每个请求的占用空间增加流量激增等情况可能会很快改变。 我建议以下文章以获取有关可用于HotSpot JVM的YoungGen空间和并发收集器的更多详细信息。 Oracle HotSpot主要是并发收集器CMS vs. G1 http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html Oracle HotSpot次要收藏全面介绍 http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html http://blog.griddynamics.com/2011/06/understanding-gc-pauses-in-jvm-hotspots_02.html 无论您使用的HotSpot GC策略如何包括大多数并发的收集器例如CMS或G1YoungGen空间收集仍然是“世界停止”事件。 据我们所知 Azul Zing C4是唯一宣传为真正的连续并发压缩收集器的JVM收集器。 目前我们还没有机会尝试使用该收集器。 我欢迎任何具有C4调优经验的人分享他们的观察结果尤其是真实的事实数据而不是像G1这样的大多数并发收集器。 现在我们已经涵盖了一些理论下面让我们深入研究示例应用程序并针对各种YoungGen占用空间和分配比率来回顾性能测试结果。 样本应用规范 为了比较各种YG分配率之间的响应度和JVM暂停时间我们根据以下规范创建了一个示例应用程序 根据以下属性已通过jvm URI创建并公开了JAX-RSRESTWeb服务。 GETPath(/jvm)Produces(MediaType.APPLICATION_JSON)public Integer jvm() {} 每次对jvm的调用都执行以下逻辑 1.分配短期对象的预定大小适用于快速YG GC。 此外在类加载时会分配1 GB的长寿命对象不适合GC的初始内存占用空间以便为CMS收集器创建一些噪音。 YG短期对象的内存分配和OldGen静态保留仅通过按照下面的代码片段创建原始字节值的静态数组即可实现。 根据使用MAT的JVM堆转储分析可以观察到真正的内存占用量。 private final static int LONG_LIVED_OBJ_FOOTPRINT (1024 * 1024 * 1024);
private final static int SHORT_LIVED_OBJ_FOOTPRINT (100 * 1024 * 1024);// 1 GB static memory footprint
private final static byte byteArrayLongLivedObj[] new byte[LONG_LIVED_OBJ_FOOTPRINT];// 100 MB memory allocation (waste) created per execution
public void generateShortLivedObj(String objId) { byte byteArrayShortLivedObj[] new byte[SHORT_LIVED_OBJ_FOOTPRINT];
} 最后在下面找到环境规格和用于创建执行和监视此YG比较性能测试的软件。 作业系统Windows 7 64-bit Java EE容器 WildFly 8 Beta1 JVMOracle HotSpot 1.7 64位Java堆大小为5 GBYG空间1152 MB XXNewRatio 3。 GC收集器CMS IDE JBoss Developer Studio 7.0.0.GA JVM监视 JVisualVM JVM内存泄漏分析器 Plumbr 3.0 JVM verbosegc日志分析器 GCMV 性能和负载测试 Apache JMeter 2.9 性能测试结果和观察 以下性能测试模拟了一个现实生活中的应用程序该应用程序需要处理大量的JVM暂停时间以及在峰值负载下的严重降级。 在模拟每个请求的应用程序内存占用量的改善减少之后执行了3次运行其中1次作为基线运行另外2次运行。 基准线 10个并发线程 每个JVM进程每次执行创建100 MB的短期对象 寿命短的对象的内存占用空间可能看起来很极端但这确实是我们最初要解决的问题。 结果 平均响应时间140毫秒 吞吐量68请求/秒 JVM总体暂停时间 25.8 YG收集频率每秒7个收集 GC速度每分钟308909 MB 按照JVisualVMJVM看起来很健康没有内存泄漏稳定且OldGen低等。 但是当您在verbosegc日志中进一步深入研究时您会意识到JVM的总体暂停时间为25.8这都是由于YG收集频率过高所致。 这有力地证明了正确分析verbosegc日志与仅关注JVM持久空间趋势的观点。 测试与调整1 10个并发线程 每个JVM进程每次执行创建50 MB的短期对象 此运行模拟了应用程序占用空间和内存分配速率从每个分配的100 MB到50 MB的初始改善。 通过简单地减少每个请求的应用程序内存占用量我们可以清楚地看到所有数字的改进特别是吞吐量。 结果 平均响应时间119 ms -21 吞吐量79要求/秒11 JVM整体暂停时间 15.59-10.21 YG收集频率每秒3-4次收集-3 GC速度每分钟164950 MB -143959 测试与调整2 10个并发线程 每个JVM进程每次执行创建5 MB的短期对象 此运行模拟了将应用程序占用空间和内存分配率从100 MB大大降低到每个分配仅5 MB的情况。 结果 平均响应时间107毫秒-33 吞吐量90请求/秒22 JVM总体暂停时间 1.9-23.9 YG收集频率每2-3秒收集1次*大幅减少 GC速度每分钟15841 MB -293068 如您所见对应用程序占用空间和内存分配的最终改进确实将JVM暂停时间显着减少到了可接受的1.9。 重要的是要注意在这3个测试中OldGen占用空间和CMS活动对JVM暂停时间没有任何实质性影响性能问题是由于活动过多以及与YG相关的世界停止事件数量过多所致集合。 解决方案和建议 我们的问题案例表明通过调整和减少每个应用程序请求的内存占用空间可以减少与过多的YG收集活动相关的JVM暂停时间从而降低分配率和YG GC频率。 但是当短期内无法使用这种调整策略时值得探索其他解决方案。 通过以下能力改进策略可以潜在地获得类似的结果 水平和垂直扩展通过增加JVM进程数量来拆分流量但以可用硬件为代价从而降低了YG集合的分配率和频率。 从本质上讲这意味着将硬件投入该问题。 我的建议始终是先微调您的应用程序内存占用量然后并行探索其他扩展选项。 Java堆大小和YG比率调整增大YG空间的大小肯定会有助于减少停止世界YG集合的频率。 现在请注意不要“饿死” OldGen空间否则您将直接解决问题并产生更严重的后果例如JVM抖动和OOM事件。 最后的话 我希望您喜欢这篇文章并且现在更好地了解过多的JVM YG集合对性能的潜在影响。 我建议您阅读本文后做以下练习 选择您最繁忙的应用程序之一。 查看verbosegc日志并通过GCMV确定JVM暂停时间。 确定YG收集的频率和影响并确定调整机会。 期待您的意见并分享您的JVM调优经验。 参考 Java VM – Java EE支持模式博客上的JCG合作伙伴 Pierre Hugues Charbonneau 提防YoungGen空间 。 翻译自: https://www.javacodegeeks.com/2013/11/java-vm-beware-of-the-younggen-space.htmljava vm
