Chinaunix首页 | 论坛 | 博客
  • 博客访问: 370253
  • 博文数量: 793
  • 博客积分: 2500
  • 博客等级: 少校
  • 技术积分: 8660
  • 用 户 组: 普通用户
  • 注册时间: 2010-06-17 23:02
文章分类

全部博文(793)

文章存档

2010年(793)

我的朋友

分类:

2010-10-08 22:44:06

  引言   这是由五部分组成的有关 aix 上的 java 性能优化系列中的第四篇文章。强烈建议您在进一步继续之前阅读本系列中的第 1 部分(如果您还没有这样做的话)。   本文讨论可能成为性能瓶颈的另外两个方面:   网络   磁盘 i/o   这两个方面通常作为特定于 aix 的问题出现,需要独立于 java 应用程序进行优化。因此,本文暂不使用第 2 部分和第 3 部分 中使用的形式,而是集中于如何找到完成优化工作所需要的信息。因此,本文仅提供了少量的技巧,但是我们希望将整体的性能工具讨论与这里的少量技巧相结合,为您提供足够的信息以着手开始性能优化工作。   i/o 和网络瓶颈   本文的目的是讨论 i/o 或网络可能成为瓶颈的情况。   如果您已经阅读了本系列中之前的每篇文章,我们希望您开始了解每个较小的部分是如何适应全局的。我们已尝试基于这些技巧的常见适用领域对其进行分类,但是此分类决不是互斥的。对于网络和 i/o,您不会如此容易地看到实际问题原因,但是您最终会感觉到它们对应用程序的影响。只有对应用程序的充分了解才能指导您确定问题根源。例如,在本系列的前面,我们讨论了确保堆不分页的重要性。使用 -xmx 开关指定的最大堆大小应该小于系统上安装的物理内存总量(通过“bootinfo –r”或“lsattr -el sys0 -a realmem”来显示,有关更多的此类命令,请参见“aix commands you should not leave home without”。   诸如 topas 和 iostat 等工具可以显示各个磁盘的使用情况,但是在大多数情况下,问题根源要么是 gc 周期,要么是某个已知的功能部分;如果您了解自己的应用程序,则确定问题根源应该是相当简单的。诸如 filemon 等工具甚至会告诉您哪些文件正在受到访问,从而从优化工作中排除猜测成分。如果您的 java 应用程序性能由于错误配置的系统而受到影响,则是改变重点并改为考虑系统性能优化的时候了。例如,磁盘瓶颈的解决方案可以是把数据进行有效的分布或者是选择使用更加高速的磁盘。此主题超出了本文的范围;有关此主题的更多信息,请参阅诸如 understanding ibm eserver pseries performance and sizing 等红皮书。 如果喜欢最大化 aix 上的 java 性能,第 4 部分: 监视流量请收藏或告诉您的好朋友.
阅读(136) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~