当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

评论: 了解 WebSphere eXtreme Scale 的关键性能指标

通过监视保持数据网格健康

John Pape, WebSphere Application Server SWAT 团队, IBM

John Pape 目前供职于 WebSphere SWAT 团队，并致力于为利用 WebSphere Application Server、WebSphere Portal Server 和 WebSphere Extended Deployment 的客户提供危急情况 (crit-sit) 支持。此角色需要关注细节并保持“标新立异”的创新思维，并始终确保 IBM 客户获得尽可能最好的支持！

简介： 与任何企业系统一样，您也应该监视 IBM® WebSphere® eXtreme Scale，让数据网格的健康状态和性能保持在最佳水平。本文帮助您了解要监视的性能指标、监视它们的方式以及可以从数据了解到什么。本文来自于 IBM WebSphere Developer Technical Journal 中文版。

标记本文！

发布日期： 2011 年 6 月 23 日
级别： 初级
原创语言： 英文
访问情况： 1295 次浏览
评论：

保持高性能

对于任何企业计算系统，要想保持它的总体健康状态，都必须进行监视。IBM® WebSphere® eXtreme Scale 也不例外。无论是把 WebSphere eXtreme Scale 部署在 IBM WebSphere Application Server 管理的 JVM（Java™ 虚拟机）还是单独的 J2SE JVM 中，都有一些相当好的监视方法。

例如，如果把 WebSphere eXtreme Scale 部署在 WebSphere Application Server 管理的环境中，就可以使用 WebSphere Application Server 的 Performance Monitoring Infrastructure (PMI) 从 WebSphere eXtreme Scale 环境的不同部分收集并分析性能指标。

无论采用哪种部署风格和哪些监视工具，本文都会指出在 WebSphere eXtreme Scale 环境中应该监视的一些关键性能指标 (KPI)。

但是，为了让这里提供的信息对您有帮助，首先给出一些假设和解释：

您应该基本了解 WebSphere eXtreme Scale 的管理和配置以及适用的监视解决方案，比如 IBM Tivoli® Performance Monitor（在 WebSphere Application Server 中）或 Wily Introscope。提出这个要求是因为本文的重点是要监视的指标和应该寻找什么信息，而不是如何通过配置环境捕捉指标本身。
下面列出的指标分为几组，从软件组合的最低层 (JVM) 直到 WebSphere eXtreme Scale 产品层上的 xsadmin 工具。这是因为在排除故障时常常需要先检查软件组合最低层的健康状态，然后逐渐向上探索，尤其是在解决与性能相关的问题时。
最后，这里指出的关键指标基于我使用 WebSphere eXtreme Scale 的经验，以及我认识的使用此产品的用户的经验。换句话说，您的情况可能不一样。

回页首

KPI 基础

我认为 WebSphere eXtreme Scale 的 KPI 分为三类，可以通过这些关键指标判断 WebSphere eXtreme Scale 环境是否健康且性能良好：

堆利用率
堆空间对于 WebSphere eXtreme Scale 环境为什么很重要，原因应该是非常明显的；驻留在容器中的所有数据必须在 Java 堆内放得下。如果用光了可用的堆空间，JVM 会执行垃圾收集（有时候很过分），从而释放足够的空间以分配应用程序所请求的对象。如果 JVM 无法为对象分配释放足够的空间，就会抛出 OutOfMemoryError 异常，表示没有分配对象所需的可用空间。

应该注意当前堆利用率随时间的变化，以此了解容器 JVM 中存储了多少数据。还应该注意内存使用量的变化趋势，这有助于做出正确的容量规划决策（即，增加更多 JVM 或提高 JVM 的最大堆大小）。
垃圾收集频率
当 JVM 执行垃圾收集时，它一般不会做其他任何事情（不同的算法行为不同）。如果 JVM 清理内存花费的时间比执行应用程序代码还长，性能就会受损。通过使用垃圾收集频率并计算每分钟花在垃圾收集操作和执行应用程序代码上的时间，可以计算出垃圾收集的开销。大多数企业监视工具会替您计算这个指标，也可以使用以下公式自己计算：

由于 GC 操作暂停执行的时间 / 总时间 = GC 开销百分比

经验法则是，如果垃圾收集开销百分比达到 10-15% 以上，那么 JVM 很可能出问题了。根据您的响应时间需求，可能无法容忍 JVM 的垃圾收集开销达到 12%。应该在环境生命周期的早期在正常负载下观察开销百分比，然后在不同的负载模式下寻找异常情况。同时观察这个指标和下面介绍的垃圾收集暂停时间会更有意义。
垃圾收集暂停时间
在垃圾收集方面，暂停时间是指 JVM 执行垃圾收集操作并锁住线程（和堆）的时间量（通常以毫秒为单位），在这些时间里不执行应用程序代码。显然，如果不运行应用程序代码，在 JVM 中就没有真正有意义的活动（例如，在容器 JVM 中，没有数据获取、复制等活动）。尽管必须忍受垃圾收集，但是暂停时间太长完全是另一回事。在大多数情况下，暂停时间太长的原因是 CPU 争用、在不够大的堆上分配过多的对象、负载过重和并发收集故障（在并发垃圾收集算法中）等等。监视这个指标很重要，可以帮助回答 “我的 WebSphere eXtreme Scale 容器是否导致响应时间很长，以致于超过 SLA 的要求？” 或 “性能下降是发生在客户端还是网格端？” 等问题。

接下来，看看 WebSphere eXtreme Scale 特有的一些性能指标，可以使用它们来判断网格客户机和容器的生存状态。

回页首

使用 Java 方法度量工具

如果您在使用某种分析工具，可以使用 WebSphere eXtreme Scale 提供的一些指标帮助了解数据网格环境中正在执行的操作。应该观察的关键指标包括：

HAControllerImpl.viewChangeCompleted
HAControllerImpl 系列指标处理核心组生命周期并反馈事件。可以通过监视这个类了解核心组的结构和变化。通过监视调用 viewChangeCompleted 方法的次数，可以了解 WebSphere eXtreme Scale 环境什么时候跨网格改变状态。例如，启动和停止网格 JVM 会触发视图变更，因为服务器要确认新的或消失的成员并更新它们的可用网格 JVM 视图。一个可以使用这个指标探察问题的场景是：您看到了这个方法的响应，这表明发生了视图变更，但是您并没有对网格的状态做任何更改（比如启动或停止网格 JVM）。这种情况可能表明一些 JVM 不健康（例如抛出了 OutOfMemoryError）、崩溃了或正在受到网络分区事件的影响。
ORBClientCoreMessageHandler.sendMessage
ORBClientCoreMessageHandler 系列指标负责发送给容器的应用程序请求。可以通过监视 sendMessage 方法了解客户机响应时间和请求数量。这个方法（和下面列出的方法）对于判断网格环境中执行网格操作（比如 CRUD 交互、查询等）花费的时间很有用。通过度量执行这个方法花费的时间，可以知道对网格的一次往返调用会花费多长时间。报告的时间包括客户机与容器 JVM 之间的网络延时，再加上在容器端处理请求花费的时间。
ShardImpl.processMessage
ShardImpl.processMessage 方法负责处理到达的客户机请求。与前一个指标相似，可以根据这个方法的执行时间判断在容器 JVM 内处理客户机请求花费多少时间。可以通过这个方法了解服务器端响应时间和请求数量。通过结合使用这个指标和其他指标，比如堆利用率，可以判断网格的工作负载是否平衡。

回页首

使用 WebSphere Application Server PMI

如果选择用 WebSphere eXtreme Scale 增强现有的 WebSphere Application Server 环境，就可以使用 WebSphere Application Server PMI 收集并显示性能指标。可以通过 WebSphere Application Server Integrated Solutions Console 用 Tivoli Performance Viewer 查看这些指标（或者使用 Jconsole 等厂商 JMX 客户机）。PMI 可以提供操作响应时间和操作/系统错误。

可以使用 WebSphere eXtreme Scale 提供的 PMI 模块提供反馈：

objectGridModule：度量每个 ObjectGrid 实例的响应时间。
mapModule：判断每个 ObjectMap 的大小。
queryModule：度量 OGQL 查询的执行时间。
agentModule：判断代理的性能如何。
hashIndexModule：度量查询索引的效力。

只需使用 PMI 指标，就可以轻松地监视网格环境中一些关键活动的健康状态，比如平均事务响应时间、批负载器响应时间、代理持续时间等等。

回页首

xsadmin

作为故障排除和监视辅助工具，您可能会忽视 xsadmin 工具。但是，xsadmin 可以提供关键的信息，如果与其他监视指标结合使用，可以更清楚地了解当前的情况。例如，如果某个容器 JVM 的响应时间指标和垃圾收集活动表现出恶化的迹象，那么使用 xsadmin 快速检查容器 JVM 可能有助于发现其原因；例如，可能会发现其他容器发生了故障，导致更多数据片段转移到这个 JVM。

xsadmin 可以提供的关键信息包括：

映射行数。
容器布置和客户机是否可以访问。
数据片段跨可用容器的布置。

监视可以提供与健康状态和性能相关的数据，而 xsadmin 通过提供拓扑数据补充监视数据，这有助于解释在其他指标中看到的现象。

回页首

结束语

要监视的指标肯定比这里讨论的 KPI 多。每个用户和环境很可能需要结合使用本文讨论的指标和其他指标。实际上，这里没有讨论一种最有价值的 KPI，这就是您专门针对自己的环境创建的指标。本文的重点是用于监视运行应用程序的系统的 KPI，但是利用您对应用程序数据流的了解创建自己的统计指标更有价值，可以通过它们更好地了解系统现象的原因。

参考资料

学习