《websphere mq故障定位分析和排除》由会员分享，可在线阅读，更多相关《websphere mq故障定位分析和排除（9页珍藏版）》请在金锄头文库上搜索。
1、目前随着我们在中国的 WebSphere MQ（MQSeries）用户数量越来越多，越来越多的用户开始对 MQ 使用时的性能优化问题提出要求，希望能够更好地使用我们的产品，并尽可能的发挥它的最大优势，这里，我根据日常积累的经验谈一谈在 MQ 性能优化方面应该考虑的因素。任何一种软件，都会存在一定的系统管理工作，WebSphere MQ 也不例外，在使用WebSphere MQ（以下简称 MQ）时，我们可能会由于配置的原因或者由于系统的原因，也可能由于 MQ 本身的原因，而遇到 MQ 运行过程中的一些故障和问题，如何能够快速地定位这些问题，分析问题发生的原因，进而快速地解决问题，恢复系统正常运行
2、呢？这需要一定的经验积累和技巧，本文将对这方面给出一些简单的提示和方法。其实，MQ 的故障分析手段很多，例如 MQ 的错误日志即是一种简单易行、快速有效的手段，通过查看错误日志往往能一针见血地迅速解决问题，另外 MQ 还提供了其它一些手段，如通过作 trace 和 FFST (First Failure support technology) 等途径，来追踪和记录错误信息，从而解决问题。作为一个跨平台的中间件产品，MQ 在各个平台上的系统管理方法也有极大的相似之处，尤其在 AIX，SUN ，HP-UNIX 等 Unix 平台和 WindowsNT/2000 平台上，本文将以 MQ for Wi
3、ndows NT/2000 为例，帮助您分析和定位产品运行过程中可能发生的问题，并给出查找问题的办法，帮助您分析问题产生的可能原因，从而给出解决问题的途径。在分析故障原因时，通常可从一个或一系列症状入手，对它们进行跟踪以发现问题发生的原因。然而，诊断问题不是解决问题。但是，问题诊断的过程常使你能够解决问题。例如，如果你发现引起问题的原因是应用程序中的一个错误，你就可以通过改正该错误来解决问题。如果在确定了问题的原因并采取了相应措施后，您仍不能解决问题，您可以和 IBM 支持中心联系以帮助您解决问题。MQ 作为一个通讯中间件产品，它的运行故障概括而言主要与网络、MQ 本身以及客户应用三个方面有关
4、，通常出现故障时，主要要从这三方面考虑，当然还需要排除和考虑其它一些额外因素，例如，是否别的应用出现异常，把内存等资源耗尽从而导致了 MQ 的运行失败等等。MQ 为我们提供了丰富的故障分析手段，例如，MQ 的系统管理命令，MQ 的各种类型的错误日志，MQ 的 trace, FFST 等。以下本篇将从错误日志、常见故障分析等几方面探讨一下 MQ的故障分析技巧。首先我们讨论对于发现问题、解决问题十分重要，也非常奏效的 MQ 提供的错误日志手段，然后讨论在 MQ 运行过程中可能会出现的问题，并给出基本的解决方案，最后简单讨论 MQ 提供的 trace 和 FFST(First Failure sup
5、port technology) 两种错误分析手段。1 错误日志分析当 MQ 运行过程中，出现问题时，我们第一个应该采取的行动应该是察看 MQ 的错误日志。注意，在这里，不要将 MQ 系统的数据日志和错误日志相混淆。MQ 的数据日志包含了data和action两部分，在 NT/2000 平台上位于/mqm/log 下（假设 MQSeries 产品安装目录为C:MQM 下），是对 MQ 的消息数据以及用户对 MQ 的操作的纪录，是用于数据备份和系统恢复时使用的，也是数据不丢失、不重复的保障。而 MQ 的错误日志是对 MQ 系统运行过程中出现错误的纪录，它是我们查找错误原因的最简单快捷，最方便有效
6、的手段。用户一定要掌握这一方法，养成察看错误日志的良好习惯。MQ 在各种层次上，为用户提供了丰富的日志文件，这些日志文件包含了所有被启动的队列管理器、有关对 MQ 的队列管理器操作、以及被启动的通道的相关信息，当队列管理器和通道等运行时，有关信息包括出现异常情况时的信息都将在日志文件中有所体现。在 Windows NT/2000 环境中，各个日志文件的位置如下(假设 MQSeries 产品安装目录为C:MQM 下) ：若队列管理器名称已知，并且处于运行状态，错误日志位于：c:mqmqmgrQMgrNameerrors若队列管理器不处于运行状态，则错误日志位于：c:mqmqmgrsSYSTEMe
7、rrors若错误与系统有关，则错误日志位于：c:mqmerrors若错误与 MQ 客户端程序有关，则错误日志位于客户机的根目录下：c:mqmerrors另外，对于 MQ for Windows NT/2000 平台, 错误信息也会被加在操作系统的 Application Log中，通过 NT/2000 操作系统提供的事件日志也可以检测和察看到。1.1 日志文件在 MQ 产品安装时，在 qmgrs 路径下会建立SYSTEM 的子目录，在 errors 子目录下会产生三个日志文件：AMQERR01.LOGAMQERR02.LOGAMQERR03.LOG当你建立了队列管理器以后，该队列管理器所需的日
8、志文件随之产生。在mqmqmgrQMgrNameerrors 子目录下会产生三个日志文件：AMQERR01.LOGAMQERR02.LOGAMQERR03.LOG每个文件的大小为：256KB。当错误信息产生后，被放在 AMQERR01.LOG 中。当 AMQERR01.LOG 大于 256KB 时，AMQERR01.LOG 中的信息被拷贝到 AMQERR02.LOG 中，新的错误信息又放在AMQERR01.LOG 文件中，依此类推。因此，最新的错误信息总是存储在 AMQERR01.LOG 中，历史信息存储在 AMQERR02.LOG 和 AMQERR03.LOG 中。我们应该按照该顺序察看错误
9、信息，并从该文件中获取信息，根据它的提示采取相应的措施，例如：如果 TCP/IP 出错，您需要检查一下网络状态是否正常；如果发现无法连接对方的队列管理器，您需要检查一下对方的 MQ 是否处于运行状态以及对方的通道侦听程序是否启动；如果错误日志显示通道未在远程定义 ，您可以检查您定义的通道的大小写是否正确等。2 常见故障分析在开始详细分析问题的原因之前，我们应该首要考虑一下可能导致问题的一些较明显的因素，或导致问题发生的最大可能性因素，这样便于把分析问题的范围限制到最小。如前所述，有关的 MQ 的异常情况的发生，通常主要与三方面的因素有关，即：MQSeries 本身网络客户的应用2.1 初步分析
10、当出现问题时，可从这三方面着手分析原因，这里，列举了一些基本问题，您可以按照此顺序来查找问题的原因。 在此之前 MQ 是否运行正常？ 从最近一次成功运行以来，是否在某些地方作过改动？ 在此之前，应用是否运行成功？ 如果您的系统曾经运行正常，那麽在出现问题之前，您对哪些部分做了改动，如：有的用户可能由于网络重新规划而更改了某个主机的 IP 地址，则可能导致通道无法连通；有的用户新设置了防火墙，则需要进行相应的配置，才能使 MQ 的通道运行正常。如果您没有对系统配置做过更改，您可以分析是否运行环境发生了变化，如：是否由于业务量的加大导致应用程序队列满了，您需要加大队列的最大深度；是否由于连接数量的
11、增加，导致无法建立新的连接，这时，您需要察看在队列管理器配置文件中，与通道相关的 MaxChannels 和 MaxActiveChannels 的配置是否足够大。 有无错误信息？ 可以察看错误日志，得到错误信息。 是否与 MQI 应用有关，利用返回码能否解释原因？ 对于每一个函数调用，MQ 都会返回一个 Completion Code 和 Reason Code，通过MQI 返回码 Reason Code，可以在 API 一层，确定错误原因， Reason Code 代表的含义可以参考编程手册，或者从 cmqc.h 头文件中获得。如： RC2035，代表没有操作权限；RC2085 ，表示没有
12、该对象；RC2080 ，表示应用程序给出的 buffer 小于消息的实际大小等。 问题能再现吗？ 从最近一次成功运行以来，是否在某些地方作过改动？ 在此之前，应用是否运行成功？ 网络是否连接正常？ 问题是否总在每天的某一固定时刻发生？ 2.2 深入分析如果初步分析无法解决问题，您必须更进一步查找原因，您可以近一步考虑如下问题：2.2.1 与队列相关的问题 1) 队列状态是否正常？ 用 DISPLAY QUEUE 命令查看队列的各项状态 用得到的队列信息进一步查看： a) 如果 CURDEPTH 达到 MAXDEPTH，表明队列深度已满，新消息已不能再进入队列，要及时处理队列中积存的消息；或者增
13、大队列的 MAXDEPTH 属性。 b) 如果CURDEPTH 还没有达到 MAXDEPTH，再考虑以下两种情况： 如果队列被设置为可触发类型的，要检查触发条件有没有满足？相关触发进程的定义是否正确？如果队列不是触发类型的，要检查队列是否为可共享的，是否允许 PUT 或GET 的操作等。 2) 消息是否成功地放入队列?如果消息没有成功地放入队列，您可以检查： 队列是否被正确定义?例如，队列的 MaxMsgLength 属性是否足够大以容纳所需大小的消息? 队列是否被允许放入? 队列是否已满?这可能意味着应用程序无法将要求的消息放入队列。 有没有另一个应用程序取得了独占队列的权力? 3) 你是否
14、可以从队列取出任何消息?如果你无法从队列中取出任何消息，检查： 其他应用程序能否从队列中取出消息? 有没有另一个应用程序取得了独占队列的权力? 如果你正在开发应用程序，检查： 你是否需要使用一个同步点? 如果使用同步点控制来放入或检出消息，它们直到工作单元被提交前不能用于其它任务。 是否等待了足够长的时间? 作为 MQGET 调用的一个选项，你可以设置等待间隔。你应该确保等待响应足够长的时间。 你是否在等待一条由消息或相关标识符（MsgId 或 CorrelId）标识的特定消息? 检查你在等待的消息的 MsgId 或 CorrelId 是否正确。成功的 MQGET 调用会把这些值设置为检索到的
15、消息的值，所以你可能要重设这些值以便成功地取出另一条消息。 您对消息是否进行了分段处理，您是否在利用 MQGET 读取消息时，采用了正确的选项(MQGMO)，从而获取消息的整体。 还要检查一下你是否能够从队列中取出另一条消息。 你期望的消息有没有被定义为持久的? 如果没有，并且 MQ 重新启动后，消息将已丢失。 4）问题是否与远程队列有关？如果问题是否与远程队列有关，则要考虑以下几个方面： 远程队列的定义是否正确； 检查通道是否启动，如果通道是可被触发的，要检查触发监视器是否运行正常； 检查往远程队列里发送消息的应用程序是否运行正常； 从错误日志中查找信息； 2.2.2 与通道相关的问题 MQ
16、Series 的通道是 MQ 的重要组成部分，是 MQ 的难点和精华，它运行正常与否对 MQ 系统的正常运行起着致关重要的作用，并且，在 MQ 的网络环境中，相当数量的异常问题与通道有关，因此，相比而言，对 MQ 通道的维护工作是 MQ 系统管理员系统管理工作的重点。下面，我们给出当通道出现异常时，判断通道状态、分析问题原因、以及解决通道问题的途径和基本手段。这里先给出有关通道的几个基本概念：1) 通道状态通道状态有 binding、running、stopping、stoped、retrying 等几种类型，当我们发出启动通道的命令之后，通道进入 binding 的状态，若网络连接畅通并且通道定义正确，它进入正常running 状态；而在异常情况下，比如网络连接有问题、通道定义不正确或通道两端的消息序列号(Message Sequence Number)不匹配等，通道即进入 re
