如何进行WebShpere MQ 运行故障的定位分析和排除

问题描述

目前随着我们在中国的WebSphereMQ(MQSeries)用户数量越来越多,越来越多的用户开始对MQ使用时的性能优化问题提出要求,希望能够更好地使用我们的产品,并尽可能的发挥它的最大优势,这里,我根据日常积累的经验谈一谈在MQ性能优化方面应该考虑的因素。任何一种软件,都会存在一定的系统管理工作,WebSphereMQ也不例外,在使用WebSphereMQ(以下简称MQ)时,我们可能会由于配置的原因或者由于系统的原因,也可能由于MQ本身的原因,而遇到MQ运行过程中的一些故障和问题,如何能够快速地定位这些问题,分析问题发生的原因,进而快速地解决问题,恢复系统正常运行呢?这需要一定的经验积累和技巧,本文将对这方面给出一些简单的提示和方法。其实,MQ的故障分析手段很多,例如MQ的错误日志即是一种简单易行、快速有效的手段,通过查看错误日志往往能一针见血地迅速解决问题,另外MQ还提供了其它一些手段,如通过作trace和FFST(FirstFailuresupporttechnology)等途径,来追踪和记录错误信息,从而解决问题。作为一个跨平台的中间件产品,MQ在各个平台上的系统管理方法也有极大的相似之处,尤其在AIX,SUN,HP-UNIX等Unix平台和WindowsNT/2000平台上,本文将以MQforWindowsNT/2000为例,帮助您分析和定位产品运行过程中可能发生的问题,并给出查找问题的办法,帮助您分析问题产生的可能原因,从而给出解决问题的途径。在分析故障原因时,通常可从一个或一系列症状入手,对它们进行跟踪以发现问题发生的原因。然而,诊断问题不是解决问题。但是,问题诊断的过程常使你能够解决问题。例如,如果你发现引起问题的原因是应用程序中的一个错误,你就可以通过改正该错误来解决问题。如果在确定了问题的原因并采取了相应措施后,您仍不能解决问题,您可以和IBM支持中心联系以帮助您解决问题。MQ作为一个通讯中间件产品,它的运行故障概括而言主要与网络、MQ本身以及客户应用三个方面有关,通常出现故障时,主要要从这三方面考虑,当然还需要排除和考虑其它一些额外因素,例如,是否别的应用出现异常,把内存等资源耗尽从而导致了MQ的运行失败等等。MQ为我们提供了丰富的故障分析手段,例如,MQ的系统管理命令,MQ的各种类型的错误日志,MQ的trace,FFST等。以下本篇将从错误日志、常见故障分析等几方面探讨一下MQ的故障分析技巧。首先我们讨论对于发现问题、解决问题十分重要,也非常奏效的MQ提供的错误日志手段,然后讨论在MQ运行过程中可能会出现的问题,并给出基本的解决方案,最后简单讨论MQ提供的trace和FFST(FirstFailuresupporttechnology)两种错误分析手段。1错误日志分析当MQ运行过程中,出现问题时,我们第一个应该采取的行动应该是察看MQ的错误日志。注意,在这里,不要将MQ系统的数据日志和错误日志相混淆。MQ的数据日志包含了"data"和"action"两部分,在NT/2000平台上位于/mqm/log下(假设MQSeries产品安装目录为C:MQM下),是对MQ的消息数据以及用户对MQ的操作的纪录,是用于数据备份和系统恢复时使用的,也是数据不丢失、不重复的保障。而MQ的错误日志是对MQ系统运行过程中出现错误的纪录,它是我们查找错误原因的最简单快捷,最方便有效的手段。用户一定要掌握这一方法,养成察看错误日志的良好习惯。MQ在各种层次上,为用户提供了丰富的日志文件,这些日志文件包含了所有被启动的队列管理器、有关对MQ的队列管理器操作、以及被启动的通道的相关信息,当队列管理器和通道等运行时,有关信息包括出现异常情况时的信息都将在日志文件中有所体现。在WindowsNT/2000环境中,各个日志文件的位置如下(假设MQSeries产品安装目录为C:MQM下):若队列管理器名称已知,并且处于运行状态,错误日志位于:c:mqmqmgrQMgrNameerrors若队列管理器不处于运行状态,则错误日志位于:c:mqmqmgrs@SYSTEMerrors若错误与系统有关,则错误日志位于:c:mqmerrors若错误与MQ客户端程序有关,则错误日志位于客户机的根目录下:c:mqmerrors另外,对于MQforWindowsNT/2000平台,错误信息也会被加在操作系统的ApplicationLog中,通过NT/2000操作系统提供的事件日志也可以检测和察看到。1.1日志文件在MQ产品安装时,在qmgrs路径下会建立@SYSTEM的子目录,在errors子目录下会产生三个日志文件:AMQERR01.LOGAMQERR02.LOGAMQERR03.LOG当你建立了队列管理器以后,该队列管理器所需的日志文件随之产生。在mqmqmgrQMgrNameerrors子目录下会产生三个日志文件:AMQERR01.LOGAMQERR02.LOGAMQERR03.LOG每个文件的大小为:256KB。当错误信息产生后,被放在AMQERR01.LOG中。当AMQERR01.LOG大于256KB时,AMQERR01.LOG中的信息被拷贝到AMQERR02.LOG中,新的错误信息又放在AMQERR01.LOG文件中,依此类推。因此,最新的错误信息总是存储在AMQERR01.LOG中,历史信息存储在AMQERR02.LOG和AMQERR03.LOG中。我们应该按照该顺序察看错误信息,并从该文件中获取信息,根据它的提示采取相应的措施,例如:如果TCP/IP出错,您需要检查一下网络状态是否正常;如果发现无法连接对方的队列管理器,您需要检查一下对方的MQ是否处于运行状态以及对方的通道侦听程序是否启动;如果错误日志显示"通道未在远程定义",您可以检查您定义的通道的大小写是否正确等。2常见故障分析在开始详细分析问题的原因之前,我们应该首要考虑一下可能导致问题的一些较明显的因素,或导致问题发生的最大可能性因素,这样便于把分析问题的范围限制到最小。如前所述,有关的MQ的异常情况的发生,通常主要与三方面的因素有关,即:MQSeries本身网络客户的应用2.1初步分析当出现问题时,可从这三方面着手分析原因,这里,列举了一些基本问题,您可以按照此顺序来查找问题的原因。在此之前MQ是否运行正常?从最近一次成功运行以来,是否在某些地方作过改动?在此之前,应用是否运行成功?如果您的系统曾经运行正常,那麽在出现问题之前,您对哪些部分做了改动,如:有的用户可能由于网络重新规划而更改了某个主机的IP地址,则可能导致通道无法连通;有的用户新设置了防火墙,则需要进行相应的配置,才能使MQ的通道运行正常。如果您没有对系统配置做过更改,您可以分析是否运行环境发生了变化,如:是否由于业务量的加大导致应用程序队列满了,您需要加大队列的最大深度;是否由于连接数量的增加,导致无法建立新的连接,这时,您需要察看在队列管理器配置文件中,与通道相关的MaxChannels和MaxActiveChannels的配置是否足够大。有无错误信息?可以察看错误日志,得到错误信息。是否与MQI应用有关,利用返回码能否解释原因?对于每一个函数调用,MQ都会返回一个CompletionCode和ReasonCode,通过MQI返回码ReasonCode,可以在API一层,确定错误原因,ReasonCode代表的含义可以参考编程手册,或者从cmqc.h头文件中获得。如:RC2035,代表没有操作权限;RC2085,表示没有该对象;RC2080,表示应用程序给出的buffer小于消息的实际大小等。问题能再现吗?从最近一次成功运行以来,是否在某些地方作过改动?在此之前,应用是否运行成功?网络是否连接正常?问题是否总在每天的某一固定时刻发生?2.2深入分析如果初步分析无法解决问题,您必须更进一步查找原因,您可以近一步考虑如下问题:2.2.1与队列相关的问题1)队列状态是否正常?用DISPLAYQUEUE命令查看队列的各项状态用得到的队列信息进一步查看:a)如果CURDEPTH达到MAXDEPTH,表明队列深度已满,新消息已不能再进入队列,要及时处理队列中积存的消息;或者增大队列的MAXDEPTH属性。b)如果CURDEPTH还没有达到MAXDEPTH,再考虑以下两种情况:如果队列被设置为可触发类型的,要检查触发条件有没有满足?相关触发进程的定义是否正确?如果队列不是触发类型的,要检查队列是否为可共享的,是否允许PUT或GET的操作等。2)消息是否成功地放入队列?如果消息没有成功地放入队列,您可以检查:队列是否被正确定义?例如,队列的MaxMsgLength属性是否足够大以容纳所需大小的消息?队列是否被允许放入?队列是否已满?这可能意味着应用程序无法将要求的消息放入队列。有没有另一个应用程序取得了独占队列的权力?3)你是否可以从队列取出任何消息?如果你无法从队列中取出任何消息,检查:其他应用程序能否从队列中取出消息?有没有另一个应用程序取得了独占队列的权力?如果你正在开发应用程序,检查:你是否需要使用一个同步点?如果使用同步点控制来放入或检出消息,它们直到工作单元被提交前不能用于其它任务。是否等待了足够长的时间?作为MQGET调用的一个选项,你可以设置等待间隔。你应该确保等待响应足够长的时间。你是否在等待一条由消息或相关标识符(MsgId或CorrelId)标识的特定消息?检查你在等待的消息的MsgId或CorrelId是否正确。成功的MQGET调用会把这些值设置为检索到的消息的值,所以你可能要重设这些值以便成功地取出另一条消息。您对消息是否进行了分段处理,您是否在利用MQGET读取消息时,采用了正确的选项(MQGMO),从而获取消息的整体。还要检查一下你是否能够从队列中取出另一条消息。你期望的消息有没有被定义为持久的?如果没有,并且MQ重新启动后,消息将已丢失。4)问题是否与远程队列有关?如果问题是否与远程队列有关,则要考虑以下几个方面:¢远程队列的定义是否正确;检查通道是否启动,如果通道是可被触发的,要检查触发监视器是否运行正常;检查往远程队列里发送消息的应用程序是否运行正常;从错误日志中查找信息;2.2.2与通道相关的问题MQSeries的通道是MQ的重要组成部分,是MQ的难点和精华,它运行正常与否对MQ系统的正常运行起着致关重要的作用,并且,在MQ的网络环境中,相当数量的异常问题与通道有关,因此,相比而言,对MQ通道的维护工作是MQ系统管理员系统管理工作的重点。下面,我们给出当通道出现异常时,判断通道状态、分析问题原因、以及解决通道问题的途径和基本手段。这里先给出有关通道的几个基本概念:1)通道状态通道状态有binding、running、stopping、stoped、retrying等几种类型,当我们发出启动通道的命令之后,通道进入binding的状态,若网络连接畅通并且通道定义正确,它进入正常running状态;而在异常情况下,比如网络连接有问题、通道定义不正确或通道两端的消息序列号(MessageSequenceNumber)不匹配等,通道即进入retrying的状态,它会根据通道定义中shortretry和longretry的次数和时间间隔依次进行shortretry和longretry,若不成功,则通道无法正常启动。2)消息序列号(MessageSequenceNumber)消息序列号是保证MQ消息传输不丢失、不复传的一个重要机制。消息序列号由发送通道分配,是通道的一个永久属性,每当发送一条消息,消息序列号就加一,正常情况下,通道两端的消息序列号或者相等或者相差为一,通道才能正常启动。通道状态异常时应采取的措施:1)查看网络连接是否畅通MQ的通讯是建立在系统网络运行正常的基础之上的,当通道不通时,要首先检查网络连接是否正常。您可以使用操作系统ping命令,也可以采用ftp方式,在两个主机之间尝试进行数据传输,以判断网络是否正常。2)查看通道定义是否正确通道所使用的传输队列定义是否正确,通道两端的定义是否匹配,如两条通道最大传输的消息长度,Messagesequencenumberwrap是否一致。若不一致,要重新定义通道,可使用MQSC命令DEFINECHANNEL命令。3)查看通道的状态用以下命令来判断通道状态:dischstatus(ChannelName)或dischs(ChannelName)其中,ChannelName代表通道的名称,该命令支持通配符,可用dischs(*)来查看所有通道的状态,当通道无法正常启动时,必须重新启动通道,可使用MQ的控制命令runmqchl命令,或MQSC命令STARTCHANNEL来启动通道。注意:如果通道的接收方状态处于STOPPED状态,必须用startchl(ReceiverChl)来重置它的状态,注意,这并不意味着启动了通道,欲启动通道,必须从发送端来启动。如果通道处于可疑(in-doubt)状态,则通道启动阶段的互相同步工作无法完成,也会导致通道无法启动。解决方案是:用ResolveChannel命令来确定通道状态;ResolveChannel命令带有两个参数:COMMIT和BACKOUT,用COMMIT参数将传输队列中的消息删除,用BACKOUT参数将传输队列中的消息重新恢复。4)查看操作系统、MQ的TCP/IP参数是否设置成功以及runmqchi进程是否处于运行状态如果您的通道在网络出现异常或对方队列管理器重启后,MQ通讯不能正常恢复,则您要检查您的操作系统的keepidle的TCP/IP相关参数是否设置成功并且生效,同时您要检查队列管理器的属性TCP:KeepAlive是否设置为Yes,另外,您的runmqchi进程是否处于运行状态。注意:上述三者共同作用,才能保证MQ通道的正常恢复,缺一不可。5)查看通道的当前消息序列号用dischstatus(ChannelName)或dischs(ChannelName)查看通道的当前一些属性值,在通道的属性值中,currentsequencenumber代表通道当前的消息序列号值,若消息序列号不一致,则可用MQSC命令RESETCHANNEL命令来将消息序列号重新置1。注意:一般情况下,只有当某一方MQ系统重新安装,队列管理器重建,或人为操作时,才会使通道的消息序列号变为1。6)查看错误日志关于MQ提供的错误日志之前已经作过较为详细的介绍,错误日志是出现异常情况时,系统管理员查找原因时要最先考虑也最为简洁奏效的办法。通道错误日志中的错误信息,往往能很快解决问题。通常从以上几方面考虑,通道问题都能迎刃而解。2.2.3死信队列如果由于某种原因,消息不能被正常发送,它会被送到死信队列中。你可以用MQSC目录DISPLAYQUEUE来查看死信队列的深度,若队列中有消息,可利用应用程序浏览消息的内容,来确定消息被放入死信队列的原因,从而确定如何处理死信中的消息。消息有可能出现在本地的队列中,也有可能出现在目的地的死信队列中。若发生前一种情况,说明本地某有正确的路由途径,可以使消息继续下传;若发生后一种情况,说明目的地一端所指定的目的队列不存在。2.2.4配置文件对于每一个队列管理器而言,都有一个名为qm.ini的配置文件,如果该配置文件被误删除,会导致"queuemanagerunavailable"类型的错误。在WindowsNT/2000平台上,该配置文件以注册表方式存在,可以使用MQ提供的图形界面进行修改。注意:对qm.ini和队列管理器属性的修改,必须在队列管理器重新启动之后才能生效。2.2.5数据日志前面曾经提到MQ的数据日志,一般情况下,中国用户大多采用循环日志,我们建议您在估算消息容量之后,确定适当的日志大小和个数。如果,在运行过程中,出现了日志写满的情况,MQ也无法正常运行,您可以采取修改qm.ini配置文件的方法,加大日志大小和个数。2.3查看系统及应用的运行情况若从上述两个方面都没有解决问题,最后您就要从系统和应用的角度去进一步分析问题了,比如,您可查看您的系统运行速度是否正常,系统资源是否耗尽等,从而确认是否系统问题影响了MQ的正常运行。3Trace错误跟踪也是一种跟踪故障的手段,在MQforWindowsNT/2000环境中,我们可以用"strmqtrc"命令来追踪问题的发生原因。Trace文件除特殊指定,一般放在mqmworkerrors目录下,文件的命名规律是:AMQppppp.TRC(注:ppppp是产生trace的进程标识符(PID))。注意:启动trace跟踪,会影响系统的性能,所以在生产环境中要慎重使用。Trace文件的内容,用户是无法分析和读懂的,要由IBM实验室进行分析。4FFST(FirstFailuresupporttechnology)在WindowsNT环境中,FFST消息文件位于c:mqmerrors目录下。这些错误一般较为严重,一般表现为系统错误或MQ内部错误。FFST文件的命名规则为:AMQnnnnn.mm.FDC,其中nnnnn-报告错误的进程标识符(PID)mm-序列号,一般为0在FDC文件中,对我们有帮助的是它的开始部分,我们可以参考它的ErrorCode,ProbeType,ProbeDescription部分的内容来分析原因。它的主要部分也是需要由IBM试验室来分析的,IBM借助MQMFunctionStack和MQMTraceHistory来分析故障原因。以上,我们初步讨论了有关MQSeries故障分析的一些方法和技巧,希望对大家有所帮助。

解决方案

解决方案二:
这篇文章不错,正在学习中
解决方案三:
很不错

时间: 2024-10-21 16:26:20

如何进行WebShpere MQ 运行故障的定位分析和排除的相关文章

CPU供电不足导致频繁死机故障的分析与排除

  最近电脑总是死机,我的CPU型号为英特尔赛扬,核心电压默认情况下为1.5V,开机后进入BIOS查看到的CPU的工作电压却仅为1.2V.以前计算机一直都比较稳定,请问如何解决这个电脑故障? [分析与排除] 从以上情况分析来看,由于CPU的默认工作电压为1.475V,如今只有1.2V的工作电压,因此造成电脑经常死的原因肯定是CPU的供电不足引起的,这种情况下很可能因为主板的元件老化,造成了供电部分的电压偏低,CPU自然就不能正常工作,死机也就在所难免了.就像是超频一样,提升频率后的CPU不会都很

vmware安装cent os 6.5 + oracle 11g xe + jboss eap 6.2 + weblogic 12c+ webshpere mq 7.5

前言: mac系统发展速度确实很快,短短数年,mac os上已经能网银支付(中行.招行.工商.支付宝等均已全面支持mac os了),windows上的经典常用软件:qq.飞信.旺旺.有道词典.有道云笔记.迅雷.PPS影音.AcdSee,甚至微软自家的office全套都有for mac,今天下定决心把mac机上vmware里的windows 7给"打入冷宫",准备把oracle.nexus.jboss.weblogic 这些跟java开发有端的"重量级"大家伙都放到c

代码-c语言的问题方面,运行故障!

问题描述 c语言的问题方面,运行故障! 看看哪里出问题了?代码也有,用的dev弄的#includeint main(){ int ijs=0t[3][4]; printf(""请输入三行四列数组元素:n""); for(i=0;i<3;i++) for(j=0;j<4;j++) { scanf(""%d""&t[i][j]); s=s+t[i][j]; } printf(""The ma

jboss EAP 6.2 + Message Drive Bean(MDB) 整合IBM Webshpere MQ 7.5

上一篇我们知道了消息驱动Bean的基本用法,实际大型分布式企业应用中,往往会采用高性能的商业Queue产品,比如IBM Webshpere MQ(目前最新版本是7.5 ),下面讲解下如何在Jboss EAP 6.2 版本上整合Webshpere MQ 7.5   一.修改jboss的standalone-full.xml a) 添加IBM的resource-adapters 找到<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1

如何降低数据中心运行故障

2015年8月6日晚上,部分QQ用户出现无法登录故障,这直接影响到了腾讯旗下多款产品的连接使用,直到22:30左右才恢复正常,事后据腾讯确认是因QQ服务机房故障而导致.而在此之前的半年多时间里,多家知名互联网企业因服务器.网络设备产生的大大小小各种故障已有数十例.对于像互联网公司这样依赖优质的网络体验而生存的企业,如果出现故障,其产生的影响和后果非常严重.   既然网络故障带来的负面作用如此之大,可如何消除这种故障呢?没有任何一家企业愿意出现这种故障,而出了故障则说明其数据中心必定存在健康问题和

数据中心网络故障维护策略分析

数据中心是由大量电子设备搭建起来的复杂信息系统,这些电子设备出现各种各样的故障是不可避免的,尤其是网络设备,就算是谷歌.脸谱.亚马逊等这些互联网巨头的数据中心也难免会发生不少故障.一旦网络设备出现故障,往往大面积的业务就会受到影响.一方面我们要增加网络设计的健壮性,关键节点部署冗余备份:另一方面要优化处理网络故障的手段,当出现网络故障时,如何快速恢复.并定位问题,消除隐患都需要诸多专业技术知识和丰富的网络经验,同时制定完善的故障处理流程,这样能大大缩短故障恢复的时间,同时还能有效找到故障原因,避

虚子雨:SEO诊断报告之网站定位分析

  大家好,我是虚子雨.对于我们做SEO的站长来说,我们需要做的就是对自己的行业做一个很好的把握,对自己的网站进行一个彻底的分析,于是随着这个需求越来越强烈,市场上就诞生了一个新的行业:SEO诊断.其实这个行业之前就有的,只是没有被单独拿出来做,之前我们接触到的SEO顾问,SEO指导等都是会为我们的公司企业做SEO诊断的,一般都是个人,很少有人拿出来单独做一个公司来做,但是A5的优化小组提出的SEO诊断让这个行业又兴起的迹象.不管怎么说,这个点选取的是非常不错的,我们的网站也的确需要做好SEO诊

唐人神等两只新股25日上市定位分析

唐人神明日上市定位分析 公司基本面分析 公司是首批农业产业化国家重点龙头企业,致力生猪产业链一体化经营,经过多年的创业发展,已经形成了"品种改良.安全饲料.健康养殖.肉品加工.品牌专卖"五大产业发展格局,在全国拥有40余家子公司.集团旗下的"唐人神"."骆驼"牌都是中国驰名商标,"唐人神"肉品和"骆驼"牌饲料都是中国名牌产品."美神"种苗通过美国NSR认证,达到美国同步育种水平.集团位列

域名投资定位分析:宁做凤尾不做鸡头

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 前几天a5版聊活动中邀请了一嘉宾来为广大站长谈域名的投资情况,看见无数的站长热情提问,我得到的不是高兴而是感叹,中国站长太多了,站长的增多导致的是互联网行业的瓜分,现正在流行且火爆的域名投资也成为了站长们的瓜分对象,那么域名投资的时候各位站长你们定位分析了吗?有自己的投资计划吗?难道真的想做鸡头? 无数的站长涌入域名投资界,带来的不是域名价格