最大化 aix 上的 java 性能，第 5 部分: 参考资料和结论

　　引言 　　这是由五个部分组成的有关 java 性能的系列的结束部分。本系列中的第一篇文章奠定了性能优化的基础，第 2、3 和 4 篇文章考虑了会影响系统可伸缩性和吞吐量的各种瓶颈。本文介绍两个先前未涉及到的重要主题，并提供案例研究和参考资料。 　　一个常见问题 (faq) 是如何将特定于 sun 的命令行开关转换为特定于 ibm 的开关。此外，任何严格的性能优化工作，例如基准测试，都不能忽略系统范围的优化。我们将在下一个部分中简要讨论这些主题。 　　随后是几个案例研究，尝试说明如何应用本系列中描述的工具和技巧来解决实际中的问题。重点在于了解和学习如何使用本系列中提到的工具和技术。 　　最后通过回顾有用的参考资料结束本文和本系列。 　　其他重要注意事项 　　本部分讨论如何将 sun java 配置转换为 ibm java 配置，以及针对 aix 应用程序的系统范围的优化。这些主题的范围相当大，我们只是略微触及皮毛。 　　转换 sun java 开关 　　如果您有一个为 sun java 而优化过的应用程序，并且正在尝试将应用程序迁移到 aix（或迁移到任何运行 ibm java 的平台），您可能已经完成了最艰巨的工作。了解应用程序特征只是成功的一半。基于对使用 sun java 进行优化工作的了解，您可以使用第 2 部分和第 3 部分 中阐述的优化技巧。 　　但是，我们经常收到有关如何将特定 sun java 命令行开关转换为等效的 ibm java 命令行开关的询问。这些开关几乎始终对应于收集，因为经过充分优化的 gc 对任何基于 java 的应用程序的性能都非常重要。由于 jvm 体系结构方面的区别，sun 和 ibm 开关之间的映射非常困难。ibm java 没有包含分代的收集器 (generational garbage collector)，并且不支持任何以 -xx 开头的命令行开关。ibm java 的“完全独立”体系结构也不基于 sun hotspot 体系结构。最容易并且在大多数情况下最快的方法是在 ibm 平台上运行应用程序时丢弃所有特定于 sun 的设置，并根据需要进行微调。但是如果您对某些 sun 开关如何映射到 ibm 开关感到好奇，请继续阅读。 　　下表尝试将 sun java gc 命令行开关转换为等效的 ibm 开关。此映射基于特定于 sun 的文章“tuning garbage collection with the 1.4.2 java? virtual machine”中描述的 sun 开关的功能。此表只用于定位 ibm java 的等效（或近似）开关这个非常特定的目的。这并不意味着取代优化实践，因为即使是堆大小要求也会差异相当大。有关 ibm java 的一般 gc 优化技巧，以及有关 ibm java 的这些和其他 gc 开关的信息，请参见“fine-tuning java garbage collection performance”。此表的创建并不涉及任何性能相关的测试，而是完全基于上面引用的参考资料中的 sun 开关用法的文档记录。 sun 开关 等效的 ibm 开关 说明 -xms、-xmx-xms、-xmx这些参数及其含义保持不变。您仍然需要执行堆大小调整。 -xx:survivorratio、-xx:newsize、 　　-xx:maxnewsize、-xx:newratio无这些开关可简单地删除，因为它们用于 gc，而 gc 不适用于 ibm java。 -xx:minheapfreeratio、-xx:maxheapfreeratio-xminf、-xmaxf堆扩展/收缩受其他因素而不只是受这些开关的控制。 -xverbose:gc、-xx:+printgcdetails-xverbose:gcibm java 的 verbosegc 跟踪格式与 sun gc 区别相当大。可以根据需要启用更详细的跟踪，但是在大多数情况下，缺省的 verbosegc 跟踪就足够了。 -xx:+useparallelgc、-xincgc、-xx:+aggressiveheap无这些是 sun 支持的各种类型的收集器。它们不适用于 ibm java。 -xx:+useconcmarksweepgc -xx:+useparnewgc-xgcpolicy:optavgpause并发低暂停 (concurrent low-pause) 收集器的作用接近于 ibm 并发标记（但在设计上是不必要的）。 -xx:+cmsparallelremarkenabled无不适用于 ibm java。 -xx:parallelgcthreads-xgcthreads至少对于 ibm java，更改此设置是不可取的。 -dsun.rmi.dgc.client.gcinterval、-dsun.rmi.dgc.server.gcinterval-dsun.rmi.dgc.client.gcinterval、-dsun.rmi.dgc.server.gcinterval请参见第 4 部分中的技巧 nio003。 　　正如上表所示，大多数情况下，把 sun 平台上的开关转换到 ibm 平台的方式就是丢弃这些开关。这使得针对 ibm java 的gc 优化工作相当简单，同时仍然提供卓越的性能。 　　系统范围的优化 　　使用诸如 schedo 和 vmo 等 aix 工具具有系统范围的影响，因此对这些工具的全面介绍超出了本系列的范围。有关这些工具的更多信息，请参见参考资料部分。 　　但是对于大多数多层应用程序（尤其是基准测试），系统范围的优化是不可避免的。存在若干可用于 aix 性能优化的优秀资源可供您参考。要了解通常需要的优化类型，您可以查看实际的已发布基准。如果查看最近针对 aix 上的 ibm java 的 specjbb 2000 结果，比方说 ，则操作系统优化如下所示： 操作系统优化 　　spinlooptime=2000 　　vmo -r -o lgpg_regions=256 -o lgpg_size=16777216 　　setsched -s rr -p 40 -p $$ 　　schedtune -t 400 -f 1 　　vmtune -s 1 　　警告：切勿在没有充分了解后果的情况下应用这些设置，因为不正确使用这些设置实际上会恶化系统性能。 　　那么上述设置有何作用呢？参阅 aix 文档，您很快就可以更好地了解这其中每个设置是做什么用的。让我们依次研究一下其中每个设置。 　　spinlooptime 控制系统在让步于另一个进程之前重试某个繁忙锁的次数。由于缺省值为 40，更高的值将告诉系统应该尝试更长的时间以待锁释放。在多处理器系统上，这样会导致更好的性能，因为忙锁重试的开销要比进程上下文切换的开销低。 　　vmo 行设置大型页的大小和数量。查看一下 java 命令行开关，您将看到正在使用 -xlp。该开关启用 java 中的大型页支持，白皮书”aix support for large page“对该开关进行了更详细的描述。如果您有内存密集型应用程序，可以试验大型页以确定它是否有帮助。与 java 配套的 sdk 指南中提供了有关此主题的更多信息。 　　setsched 行实际上是一个脚本而不是 aix 命令。它调用 thread_setsched 内核服务以选择固定优先级的循环调度，并对该 java 进程使用优先级 40。 　　schedtune 命令也是 aix 5.2 以上版本中的一个脚本，它将传递的参数映射到新的 schedo 命令。上面这一行命令是将固定优先级线程的时间片更改为 400 个计时单元。它还强制固定优先级的线程驻留在全局运行队列中。 如果喜欢最大化 aix 上的 java 性能，第 5 部分: 参考资料和结论请收藏或告诉您的好朋友.