中国十大做网站公司排名,新媒体运营培训班,网站建设文化信息,中企动力app确定生产系统合适的Java堆大小不是一件容易的事。 在我的Java EE企业经验中#xff0c;我发现由于Java堆容量和调整不足而导致的多个性能问题。 本文将为您提供5个技巧#xff0c;这些技巧可以帮助您确定当前或新生产环境的最佳Java堆大小。 这些技巧中的一些对于预防和解决j… 确定生产系统合适的Java堆大小不是一件容易的事。 在我的Java EE企业经验中我发现由于Java堆容量和调整不足而导致的多个性能问题。 本文将为您提供5个技巧这些技巧可以帮助您确定当前或新生产环境的最佳Java堆大小。 这些技巧中的一些对于预防和解决java.lang.OutOfMemoryError问题也非常有用。 包括内存泄漏。 请注意这些技巧旨在“帮助您”确定适当的Java堆大小。 由于每个IT环境都是唯一的因此您实际上处于最佳位置可以精确地确定客户端环境所需的Java Heap规范。 其中一些技巧可能也不适用于非常小的Java独立应用程序但是我仍然建议您阅读整篇文章。 未来的文章将包含有关如何为您的环境和应用程序选择正确的Java VM垃圾收集器类型的提示。 1 – JVM您总是担心自己不了解的内容 您如何期望对您不了解的内容进行配置调整和故障排除 您可能永远没有机会编写和改进Java VM规范但是您仍然可以自由学习它的基础以提高您的知识和故障排除技能。 有些人可能会不同意但是从我的角度来看认为Java程序员不需要了解内部JVM内存管理的想法是一种幻想。 对于Java和Java EE初学者来说Java Heap调优和故障排除尤其是一项挑战。 在以下典型情况下查找 –您的客户端生产环境经常面临OutOfMemoryError并造成大量业务影响。 您的支持团队承受着解决此问题的压力 –通过Google的快速搜索您可以找到类似问题的示例现在您认为并假设自己面临相同的问题 –然后抓取JVM -Xms和 -Xmx值来自另一个人的OutOfMemoryError问题案例希望能快速解决客户的问题 –然后继续对您的环境实施相同的调整。 2天后您意识到问题仍在发生甚至更糟或稍好一点……斗争仍在继续…… 什么地方出了错 –您首先没有正确了解问题的根本原因 –您可能还没有从更深层次上正确地了解您的生产环境规格负载情况等。 网络搜索是学习和共享知识的好方法但您必须执行自己的尽职调查和根本原因分析 –您可能还缺少一些有关JVM及其内部内存管理的基本知识从而使您无法将所有点连接在一起 我给您的1技巧和建议是学习和理解JVM的基本原理及其不同的内存空间。 这些知识很关键因为它将使您能够向客户提出有效建议并正确理解与将来的调整注意事项相关的可能影响和风险。 现在在下面找到有关Java VM的快速高级参考指南 Java VM内存最多分为3个内存空间 Java堆 。 适用于所有JVM供应商通常在YoungGen苗圃和OldGen租用空间之间划分。 PermGen 永久代。 仅适用于Sun HotSpot VMPermGen空间将在以后的Java 7或Java 8更新中删除 本机堆 C-Heap。 适用于所有JVM供应商。 我建议您阅读以下每篇文章包括有关HotSpot Java内存管理的Sun白皮书。 我也鼓励您下载并查看OpenJDK实现。 ## Sun HotSpot VM http://javaeesupportpatterns.blogspot.com/2011/08/java-heap-space-hotspot-vm.html ## IBM VM http://javaeesupportpatterns.blogspot.com/2012/02/java-heap-space-ibm-vm.html ## Oracle JRockit VM http://javaeesupportpatterns.blogspot.com/2012/02/java-heap-space-jrockit- vm.html ## SunOracle– Java内存管理白皮书 http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf ## OpenJDK –开源Java实现 http://openjdk.java.net/ 如您所见Java VM内存管理比通过–Xmx设置可能的最大值要复杂得多。 您必须从各个角度考虑问题包括您的本机和PermGen空间要求以及来自物理主机的物理内存可用性和CPU内核数量。 由于Java Heap和本机Heap处于竞争之中因此对于32位JVM来说它尤其棘手。 Java堆越大本机堆越小。 尝试为32位VM例如.2.5 GB 设置较大的堆会增加本机OutOfMemoryError的风险具体取决于您的应用程序占用空间线程数等。64位JVM解决了此问题但您仍然限于物理资源可用性和垃圾收集开销大型GC收集的成本随大小而增加。 最重要的是越大并不总是越好因此请不要假定您可以在单个16 GB 64位JVM进程上运行所有20个Java EE应用程序。 2 –数据和应用程序为王查看您的静态占用空间要求 您的应用程序及其关联数据将指示Java Heap占用空间要求。 静态内存是指“可预测的”内存需求如下所示。 –确定要计划部署到单个JVM进程的多少个不同的应用程序例如EAR文件WAR文件jar文件的数量。您部署到单个JVM的应用程序越多对本机堆的需求就越高 –确定在运行时可能会加载多少个Java类 包括第三方API。 您在运行时加载的类加载器和类越多对HotSpot VM PermGen空间和与内部JIT相关的优化对象的需求就越高 –确定数据缓存占用空间例如由应用程序和第三方API加载的内部缓存数据结构例如从数据库缓存的数据从文件读取的数据等。您使用的数据缓存越多对Java Heap OldGen的需求就越高空间 –确定允许您的中间件创建的线程数。 这非常重要因为Java线程需要足够的本机内存否则将引发OutOfMemoryError。 例如如果您打算在单个JVM进程上部署10个单独的EAR应用程序而不是2个或3个则将需要更多的本机内存和PermGen空间。未序列化到磁盘或数据库的数据缓存将需要从磁盘上获得额外的内存。 OldGen空间。 尝试合理估计静态内存占用量。 在进行真正的测量练习之前这对于设置一些起点JVM容量数字非常有用例如技巧4。 对于32位JVM我通常不建议Java Heap大小大于2 GB-Xms2048m-Xmx2048m因为您需要足够的内存用于PermGen并需要足够的Java EE应用程序和线程本机堆。 此评估尤为重要因为在单个32位JVM进程中部署的应用程序过多很容易导致本机堆耗尽。 特别是在多线程环境中。 对于64位JVM通常建议每个Java进程3 GB或4 GB的Java堆大小。 3 –商业流量设定规则查看您的动态足迹需求 您的业务流量通常会决定您的动态内存占用量。 并发用户和请求会生成JVM GC“心跳”由于频繁创建和废弃短期和长期存在的对象您可以从各种监视工具中观察到它们。 从上面的JVM图表中可以看到YoungGen与OldGen的典型比率是13或33。 对于典型的32位JVMJava Heap大小设置为2 GB使用分代和并发收集器通常将为YoungGen空间分配500 MB为OldGen空间分配1.5 GB。 最小化主要GC收集的频率是获得最佳性能的关键方面因此了解并估算峰值量期间需要多少内存非常重要。 同样您的应用程序和数据类型将决定您需要多少内存。 涉及大型和非序列化会话数据的购物车类型的应用程序寿命长的对象通常需要大型Java堆和大量OldGen空间。 无状态和XML处理繁重的应用程序很多短期对象需要适当的YoungGen空间以最大程度地减少主要集合的频率。 例 –您要部署5个EAR应用程序约2000个Java类还包括中间件代码… –您的本机堆需求估计为1 GB必须足够大以处理线程创建等–您的PermGen空间估计为512 MB –内部静态数据缓存估计为500 MB –在高峰时段您的总预测流量为5000个并发用户 –每个用户会话数据占用量估计为500 K –仅会话数据所需的总占用空间为峰值容量以下的2.5 GB 如您所见根据这种要求您不可能将所有这些流量发送到单个JVM 32位进程。 一个典型的解决方案涉及在几个JVM进程和/或物理主机之间分配流量技巧5假设您有足够的可用硬件和CPU内核。 但是对于此示例由于对静态内存的需求很高并且从长远来看要确保可扩展的环境我还建议您使用64位VM但是以较小的Java Heap作为起点例如3 GB以最大程度地减少GC成本。 您绝对希望为OldGen空间留出额外的缓冲区因此我通常建议在大型采集后最多保留50的内存以保持Full GC的频率较低并为故障转移方案提供足够的缓冲区。 在大多数情况下除非您需要大量的数据缓存以实现适当的性能这对于门户媒体繁重的应用程序是典型的否则业务流量将占用您的大部分内存。 太多的数据缓存会产生一个黄色标记您可能需要早于稍后重新访问某些设计元素。 4 –不要猜测要衡量 此时您应该 –了解基本的JVM原理和内存空间 –对所有应用程序及其特征大小类型动态流量无状态对象与有状态对象内部内存缓存等有深入的了解和了解。 –对每个应用程序的业务流量并发用户数等以及每个应用程序都具有很好的视图或预测–如果需要是否需要64位VM以及从哪个JVM设置开始可以有一些想法 –一些想法如果您需要多个JVM中间件进程 但是等等您的工作尚未完成。 尽管以上信息至关重要并且对您提出“最佳猜测” Java Heap设置非常有用但它始终是最好的建议您通过适当的性能分析加载和性能模拟应用程序行为并验证Java Heap内存需求测试。 您可以学习和利用JProfiler之类的工具未来的文章将包括有关JProfiler的教程。 从我的角度来看学习如何使用事件探查器是正确了解应用程序内存占用量的最佳方法。 我用于现有生产环境的另一种方法是使用Eclipse MAT工具进行堆转储分析。 堆转储分析功能非常强大它使您可以查看和了解Java Heap的整个内存占用量包括与类加载器相关的数据并且在任何内存占用量分析中都必须进行此练习。 特别是内存泄漏。 Java分析器和堆转储分析工具使您能够了解和验证应用程序的内存占用量包括检测和解决内存泄漏。 负载和性能测试也是必须的因为这将允许您通过模拟预测的并发用户来验证较早的估计。 它还将暴露您的应用程序瓶颈并允许您进一步微调JVM设置。 您可以使用诸如Apache JMeter之类的工具这些工具非常易于学习和使用也可以探索其他商业产品。 最后我经常看到Java EE环境运行良好直到基础架构的一部分开始出现故障例如硬件故障为止。 突然环境以减少的容量运行JVM进程的数量减少并且整个环境崩溃了。 发生了什么 有许多情况可能导致多米诺骨牌效应但是JVM调优和处理故障转移 短期额外负载的能力非常普遍。 如果您的JVM进程以80的OldGen空间容量运行并且具有频繁的垃圾回收那么您如何期望处理任何故障转移方案 前面执行的负载和性能测试练习应该模拟这种情况并且应该适当地调整调整设置以便Java Heap有足够的缓冲区来在短期内处理额外的负载额外的对象。 这主要适用于动态内存占用量因为故障转移意味着将一定百分比的并发用户重定向到可用的JVM进程中间件实例。 5 –分而治之 至此您已经执行了数十次负载测试迭代。 您知道您的JVM不会泄漏内存。 您的应用程序内存占用空间无法再减少。 您尝试了几种调优策略例如使用10 GB 的大型64位Java堆空间多个GC策略但仍然找不到可接受的性能级别 根据我的经验我发现在当前的JVM规范下适当的垂直和水平扩展会涉及为每个物理主机以及跨多个主机创建几个JVM进程从而为您提供所需的吞吐量和容量。 如果将您的应用程序列表分为几个逻辑孤岛具有各自的JVM进程线程和调整值则您的IT环境也将具有更高的容错能力。 这种“分而治之”的策略涉及将您的应用程序流量拆分到多个JVM进程并将为您提供 –减少了每个JVM进程的Java堆大小静态和动态覆盖 –降低了JVM调整的复杂性 –减少了每个JVM进程的GC经过和暂停时间 –增强的冗余和故障转移功能 –与最新的云和IT虚拟化策略保持一致 最重要的是当您发现自己花费太多时间来调整单个大象的64位JVM进程时就该重新审视您的中间件和JVM部署策略并利用纵向和横向扩展优势了。 这种实施策略对硬件的负担更大但从长远来看确实会有所回报。 请提供任何评论并分享您对JVM Heap调整大小和调整的经验。 参考 Java EE支持模式和Java教程博客中的JCG合作伙伴 Pierre-Hugues Charbonneau提供了5个有关适当的Java堆大小的技巧 。 翻译自: https://www.javacodegeeks.com/2012/07/5-tips-for-proper-java-heap-size.html
