相对较小的房间（Nikko Carmel I / II）挤满了人，似乎只靠近站立的房间（坐席帮助每个人就座）。 早上的策略性主题演讲稍有结束，人们在试图离开时陷入了宴会厅，而本次演讲的提早开始导致很多人迟到，这有些分散注意力。 我不怪演讲者提早开始，因为他有很多很好的信息要讲。 最大的问题是后勤延迟迫使人们离开已经超过计划的结束时间的主题演讲。
Muray具有七个虚拟化最佳实践，只有前两个（虚拟机内存和虚拟CPU /物理CPU /线程）是Java特有的。 大多数人在存储区域而不是处理/ CPU区域犯了虚拟化错误。 Murray指出，Java开发人员无需执行任何操作即可使用虚拟化。 他们不需要更改任何代码，也不需要更改任何设置。
- 虚拟机内存
- 中央处理器
- 磁盘I / O
- 网络I / O
- 计时表
- 微观基准
- 监控与管理
一个易于理解的虚拟化Java应用程序的初始最佳实践是：“ Java堆需要始终保持在物理内存中。” 他还建议使用大内存页。 不要将那么多虚拟机塞入物理内存，以使每个VM的总最大堆空间使用的内存多于物理内存中可用的内存。
默里的第一个正式最佳实践是“ 1。 虚拟机内存：调整虚拟机的内存大小以留出足够的空间。” 他指出，有一个公式可以计算要使用的内存量，以考虑该内存的许多需求。 他说，此公式已记录在白皮书和同事的书中。 Murray说，虽然对于一个小型应用程序可能有太多的JVM内存，但他通常赞成为JVM分配大量的内存以用于虚拟化。 Murray还建议使用VMware Distributed Resource Scheduler（DRS） 。 他的另一个广告宣传是针对Java的vFabric弹性内存（EM4J），它与VMware的称为“ tc服务器 ”的“ Tomcat之味”一起提供。 Murray表示，尽管在大多数情况下都担心Java中内存的过度使用，但在使用tc服务器和EM4J时并不需要。 Murray还使用了esxtop 。
解决了内存问题后，Murray转向了主要的CPU。 他从对线程和虚拟CPU的观察开始本节。 他的幻灯片中写道：“ Java线程可随时在一个vCPU上执行”，而“ vCPU则可随时在一个物理CPU上调度。” Murray补充说，他与之合作的大多数客户正在使用四个虚拟CPU，但现在最多支持32个虚拟CPU。线程通常在监视器或套接字上等待释放，并且Murray认为大多数Java应用程序并未完全使用theads。 通常，Murray倾向于使用“对您的应用程序来说实用的虚拟CPU数量最少”。 Murray表示，使用命令行选项-Xgcthreads等同于说：“我比JVM更了解。”
Murray表示虚拟化不再害怕I / O。 他说，从Java虚拟化的角度来看，网络I / O比磁盘I / O更重要。 Murray指出，交换对物理机上的VM不利，对于虚拟机上的VM同样不利。
Murray提供的一个更好的建议应该被更普遍地理解（但似乎不是），它只是对自己的应用程序进行基准测试，并且仅基于特定应用程序的基准测试来做出决策。 他补充说，使用应用程序的“代表性子集”还不够好。
为了进行监视和管理，Murray建议从每台计算机开始一个JVM进程，然后逐步扩展到虚拟机中所需的JVM数量，一次确定一个上限。 他在幻灯片上的最后一个项目符号建议使用vCenter或esxtop来查看Java应用程序的哪些部分正在消耗资源。
Murray的“简短故事”是，对于虚拟化而言，Java开发人员通常不需要调整JVM垃圾回收策略，线程池大小或JDBC连接池大小，而对于物理服务器则不需要进行任何调整。 唯一应使用的命令行选项是用于指定大页面。
Murray讨论了使用Capacity Planner进行大约30天的收集，以了解哪些候选人是虚拟化的良好候选人。 Murray指出，您不能凭空创建硬件，因此在这种情况下，虚拟化将无法帮助大量使用硬件。
Murray总结说：“ Java中间件和应用程序应该虚拟化。”
Murray在VMware工作，VMware 在VMware最佳实践指南上提供了企业Java应用程序 。 Murray在演讲中引用了VMware的技术白皮书 。
参考： JavaOne 2011：虚拟化Java应用程序： JCG合作伙伴的 最佳实践 实际事件启发博客中的达斯汀·马克思。
翻译自: https://www.javacodegeeks.com/2012/02/virtualizing-your-java-applications.html
查询后求总数(count))
