PS：此文章对cluster的channel介绍的较少。

1. 概述

WebSphere MQ作为IBM软件家族的消息传输中间件产品，以其出色的特性和功能在业界享有盛誉。WebSphere MQ独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性，以及强大的消息通讯能力，使得它在银行、电信，还是在交通运输、政府机关等各行各业，赢得了很高的市场份额。在中国，WebSphere MQ同样拥有广泛的用户基础和许许多多的成功案例。它不仅具有跨平台、跨网络的特性，而且以其特有的先进机制保证对消息的"Once and Once only"的传输，做到不丢失、不复传。在WebSphere MQ给客户带来的众多价值中，有一点十分重要，就是它的通讯感知和恢复机制，尤其适用于我国目前的现状，在我国很多地方存在网络线路质量差，网络状态不稳定的现状。因为WebSphere MQ在支持同步通讯的同时，提供了基于消息队列存储-转发机制的异步通讯模式，应用程序只需将消息交给WebSphere MQ，就由WebSphere MQ负责将消息安全、可靠地发送出去，不再需要应用和人工的干预，当网络出现故障的情况下，或对方主机发生故障时，WebSphere MQ能够作到不需要人工干预，自动探测网络状况的好坏，并且在网络恢复正常之后能够继续正常工作，也即断点续传。

在WebSphere MQ的系统配置和维护中，通道(Channel)的配置和维护是较复杂也是最重要的部分，本文将对如何配置和维护WebSphere MQ消息通道进行介绍，并附录有关实现WebSphere MQ队列管理器双向通讯对象配置脚本。

2. 消息通道的配置 2.1 消息通道的类型

消息通道是把消息从一个队列管理器送到另一个队列管理器的通道。不要和MQI通道混淆，MQI通道是在MQ客户端和MQ服务器队列管理器之间发送消息的通道。我们这里讨论的是消息通道。WebSphere MQ中通信双方的消息通道类型有6种：

Sender

Receiver

Server

Requester

Cluster sender

Cluster receiver

上述消息通道类型配对共有5种：

Sender-receiver

Requester-server

Requester-sender(callback)

Server-receiver

Cluster sender-cluster receiver

下面分别对各种组合进行介绍，并给出配置脚本

2.1.1 Sender-receiver

Sender/Receiver通道是最常见的通道配置方式，Sender作为通道的发送方也是通道连接的主动发起方，Receiver作为通道的接收方也是通道连接的被动监听方。

在下面配置脚本中，通道连接两个队列管理器QM1和QM2。其中，QM1为Sender方，QM2为Receiver方。在QM1上配置了远程队列（QR2）和传输队列（TO.QM2），其中QR2指向队列管理器QM2上的本地队列（QL2），且QR2与TO.QMB2对应，即凡是要放入QR2队列的消息，在加上传输消息头后直接放入TO.QM2中等待发送。QM1上配置Sender通道（QM1.QM2）需要指定传输队列名以及对方的通信参数（IP地址和端口），通信参数必须与QM2上的侦听程序设置匹配。

Sender通道与传输队列TO.QM2对应，表示凡是在TO.QM2中等待发送的消息最终都可以由该通道送出。双方通道必须同名。

在连接通道的时候，我们只需在QM1端启动通道Start channel(QM1.QM2)。

2.1.2 Server-receiver

Server/Receiver与sender/Receiver类似。Server端是消息的发送方，也是连接的发起方。在配置的时候，必须指定对方的通信参数，由CONNAME设定。

2.1.3 Server-requester

Server/Requester通道也是一种较常见的通道配置方式，如图2所示。从消息流向来看，Server作为消息的发送方，requester作为消息的接收方。但是从连接方式来看，requester却是连接的主动方，server是被动方。这种模式常用于动态IP地址的环境中，Server是静态IP地址的服务器，Requester的机器上网后自动分配到一个IP地址，所以是动态的，由Requester发起连接后接收数据。

2.1.4 Sender-requester

Sender/Requester的连接过程稍微复杂一些，如图3所示。Requester首先与Sender连接，在通知对方连接参数后连接断开。Sender进行反向连接，消息也是反向传送的，即由Sender传给requester。这种反向连接的方式，称为回调连接（callback connection）。这种模式也常用于做双向验证，即双方必须都要知道对方的通信参数才能完成回调连接。

2.1.5 Cluster sender-cluster receiver

在一个cluster环境中，每一个队列管理器都一个Cluster sender通道，通过这个通道把消息发送到完全资源队列管理器，每一个队列管理器也有一个cluster-receiver通道可以用来接收cluster中的消息。

在本文中我们不重点介绍cluster sender-cluster receiver通道。

2.2 消息通道的触发机制 2.2.1 触发器原理

触发（Triggering），是一种自动启动应用程序的机制。

队列管理器把某种条件称为触发事件。如果队列被设置为触发类型，并且触发事件发生了，那么队列管理器将发送一个触发消息到一个称作启动队列的队列中。触发消息被放置到启动队列的过程意味着产生了触发事件。

处理队列管理器中的消息是触发监控程序(Trigger-Monitor Application)，他的工作是读取触发消息并根据触发消息的信息做出相应的处理。触发监控程序没有什么特殊，它只不过是从启动队列读取消息的应用程序。

当队列管理器发现由一条消息到达被触发的队列之后，它产生的触发消息将被存放到启动队列中，触发监控程序将从启动队列中取出触发消息，并根据触发消息中的内容，启动相应的消息处理程序来处理被触发队列中的消息。

触发所涉及的对象如下所示：

1) 应用队列(Application Queue)：一个本地队列并设置为可触发。当触发条件满足时，将会产生触发消息。

2) 传输队列：如果用触发方式来启动通道，则传输队列将对应了触发的应用队列。在传输队列的TriggerData属性中设置为将被启动的通道名，这将省略进程的定义。

3) 进程定义(Process Object)：一个应用队列可能由一个进程定义对象和它关联。进程定义中包含应用程序的信息。该应用程序负责从应用队列中取出消息。

4) 触发事件：它是一种引起队列管理器产生触发消息的事件。

5) 触发消息：当触发事件发生时，队列管理器将产生触发消息。触发信息来自于应用队列和于应用队列关联的进程定义，它包含了将要被启动的程序名。

6) 启动队列：一个本地队列。被用来存发触发消息的队列。一个队列管理器可用拥有多个启动队列。一个启动队列可以为多个应用队列服务。

7) 触发监控器：是一个持续运行的程序，当一个触发消息到达启动队列时，触发监控器获取触发消息，并利用触发消息中的信息，启动应用程序来处理应用队列中的消息，并把触发消息头发送传递给应用程序，消息头中包含应用队列名。

在所有平台上，都有一个特殊的触发监控器叫做通道启动器（Channel Initator），它的作用就是启动通道。

2.2.2 触发类型

EVERY：

应用队列中每接受到一个消息时，都将产生触发消息。如果应用程序仅仅处理一个消息就结束，可采用这种触发类型。

FIRST：

应用队列中消息从0变为1时会触发事件。如果当队列中的一个消息到达时启动程序，直到处理完所有消息才结束，则采用这种触发类型。

DEPTH：

应用队列中消息数目和TriggerDepth（引起触发事件发生时，队列中的消息数目）属性值相同时，才会产生触发事件。当一系列请求的回复都收到时，才启动应用程序，则可以采用这种方法。

需要注意的时，当DEPTH属性值为0的时候，实际上就形成了同步通信。另外，当采用Depth触发时，产生触发消息以后，队列将被修改为非触发方式，如果需要再次触发，需要重新设置成允许触发。

一般而言，在实际应用中，如果通道设置成触发方式，触发类型往往设置成为FIRST和DEPTH。

2.2.3 触发器工作流程

1) 本地或远程应用程序A，往应用队列(Application Queue)中PUT了一条消息。

2) 如果队列的触发类型设置为first，当队列原来深度为0时（队列为空），这时PUT一条消息到队列中将形成触发事件，同时产生一条触发消息，触发消息中将包含进程定义中的信息，因为进程定义中包含启动程序B所需的信息，所以触发消息中也包含了启动程序B所需的信息。

3) 队列管理器创建触发消息，并把它PUT入与应用队列相关的启动队列Initiation Queue。

4) 触发监控器(Trigger Monitor)从启动队列(Initiation Queue)中GET触发消息。

5) 触发监控器处理触发消息，发出启动应用程序B的命令。

6) 应用程序B打开应用队列(Application Queue)，并处理队列中的消息。

注：如果是通道触发将可以不需要创建进程对象（process object），只是在传输队列的trigdata中设置需要启动的通道名。

2.2.4 配置消息通道触发

配置消息通道触发启动，需要使用到的对象有传输队列，通道启动队列，发送通道，通道启动器。我们本配置案例中传输队列名是QMB，通道启动队列采用SYSTEM.CHANNEL.INITQ，发送通道名QMA.QMB，通道启动器为runmqchi，该进程在队列管理器启动的时候自动启动。下面我们通过举例来演示配置实现消息通道触发启动。

首先我们来查看一下传输队列QMB都有哪些属性，显示如下清单所示，其中清单中的标注红色的属性和通道触发配置相关。

dis ql(QMB)

1 : dis ql(QMB)

AMQ8409: 显示队列细节。

QUEUE(QMB) TYPE(QLOCAL)

ACCTQ(QMGR) ALTDATE(2009-02-06)

ALTTIME(11.41.44) BOQNAME( )

BOTHRESH(0) CLUSNL( )

CLUSTER( ) CLWLPRTY(0)

CLWLRANK(0) CLWLUSEQ(QMGR)

CRDATE(2008-12-05) CRTIME(10.37.53)

CURDEPTH(0) DEFBIND(OPEN)

DEFPRTY(0) DEFPSIST(NO)

DEFSOPT(SHARED) DEFTYPE(PREDEFINED)

DESCR( ) DISTL(YES)

GET(ENABLED) HARDENBO

INITQ( ) IPPROCS(1)

MAXDEPTH(5000) MAXMSGL(4194304)

MONQ(QMGR) MSGDLVSQ(PRIORITY)

TRIGGER NPMCLASS(NORMAL)

OPPROCS(1) PROCESS( )

PUT(ENABLED) QDEPTHHI(80)

QDEPTHLO(20) QDPHIEV(DISABLED)

QDPLOEV(DISABLED) QDPMAXEV(ENABLED)

QSVCIEV(NONE) QSVCINT(999999999)

RETINTVL(999999999) SCOPE(QMGR)

SHARE STATQ(QMGR)

TRIGDATA( ) TRIGDPTH(1)

TRIGMPRI(0) TRIGTYPE(FIRST)

USAGE(XMITQ)

设置传输队列为触发模式TRIGGER。

设置触发类型为every/first/depth其中的一种，例如TRIGTYPE(FIRST)。如果设置为TRIGTYPE(DEPTH)，则还需要设置触发深度属性，例如TRIGDPTH(4)，表示当队列中的消息数由3个增加到4个的时候才能形成触发事件，但需要注意的是深度触发事件只能产生一次事情，下次传输队列的消息数由3个增加到4个时候不会产生触发事件，所以在消息通道触发中，我们推荐采用TRIGTYPE(FIRST)。

在通道触发中，推荐使用SYSTEM.CHANNEL.INITQ队列作为初始队列， 该队列为MQ专用的通道启动队列, 不需要手工启动其触发监视器，设置传输队列INITQ(SYSTEM.CHANNEL.INITQ )属性。

通过TRIGDATA属性设置需要触发的通道名，例如TRIGDATA(QMA.QMB )。

对于TRIGMPRI属性的含义是基于消息优先级触发，也即某类优先级的消息满足的触发条件才产生触发事件，我们在消息通道触发中不推荐使用。

完整MQSC命令参考如下：

ALTER QL(QMB) +

TRIGGER +

TRIGTYPE(FIRST) +

INITQ(SYSTEM.CHANNEL.INITQ) +

TRIGDATA(QMA.QMB)

通道的触发监控器我们采用系统的自带的runmqchi程序，缺省队列管理器启动的时候，runmqchi进程会自动启动。

2.3 通道主要属性

消息通道的属性非常多，下面对一些重要属性进行介绍。

2.3.1 Channel type属性

通过的类型(CHLTYPE)有很多种，需要根据通道配对方式，设置您所需要的通道类型。请参看2.1小通道类型。

2.3.2 Connection name属性

作为消息通道，只有Sender，Server 和 Requester通道才使用Connection Name(CONNAME)属性。如果通讯协议是TCPIP，该属性设置可以指定通信对方的IP地址和端口号。

2.3.3 Transmission queue name属性

Transmission queue name(XMITQ) 属性是设置传输队列名，就是通道需要从这个队列取出消息然后发送到对方。sender 和server通道需要设置XMITQ属性。

2.3.4 Disconnect interval属性

Disconnect Interval(DISCINT)是发送和服务类型的通道所具有的一个参数，它的作用是：在它设置的时间间隔内，如果传输队列为空即通道上没有消息通过时，通道就会被停止。设置完Disconnect Interval参数之后，当发送方重起通道时，通道就会被正常启动。

Disconnect Interval的值会地影响通道的性能。如果把Disconnect Interval的值设置得非常小，会导致通道的频繁启动；反之，如果把Disconnect Interval的值设置得很大，则意味着即使通道上很长时间没有消息，系统资源也会被长期占用，从而影响系统的性能。因此，利用改变Disconnect Interval的值，我们可以有效地改善通道的性能。

当传输队列中没有消息要传送时， 发送方通道(SDR)、服务器通道(SVR)将在等待了该 参数指定的时间间隔后断开连接，停止通道。该参数以秒为单位，定义新的通道时，如果没有特别指定，该参数会继承系统对象的属性，设为6000秒，约两个小时。亦通道连续两个小时没有消息发送后就会停止。DISCINT参数设定为0，通道永远不会停止。

2.3.5 Heart Beat Interval属性

与Disconnect Interval(HBINT)相对应的是Heart Beat Interval这一参数(仅针对WebSphere MQ for AIX、HP-UX、OS/2、Sun Solaris、Windows NT/2000 V5.1以上)。它的作用是：在Heart Beat Interval指定的时间间隔内，如果传输队列上没有一直没有消息到达，发送方MCA会向接收方MCA发送一个心跳信号，据此给接收方通道以停止的机会，在这种情况下，它不必等待Disconnect Interval超时，也会将通道停止下来。同时，它会释放用来存贮大消息的内存空间并关闭接收方的队列。

为了使HeartBeat Interval和Disconnect Interval这两个参数更有效地发挥作用，一般情况下需要让Heart Beat Interval设置值小于Disconnect Interval设置值。

另外，如果我们使用的传输协议是TCP/IP，我们也可以利用设置TCP/IP的socket的SO_KEEPALIVE参数来实现这一功能。设置完SO_KEEPALIVE参数，并设置时间间隔之后，TCP/IP本身就会定期去检测另一端连接的状态，如果对方连接已断开，通道也会被停止。在这里，TCP/IP的时间间隔也应小于WebSphere MQ通道的Disconnect Interval的值。

2.3.6 ShortRetry和LongRetry属性

在发送类型等类型的通道属性中，还有四个参数是与通讯恢复和通道连接有关的，它们是：shortrty,shorttmr,longrty,longtmr,它们的缺省值分别是：10，60，999999999，1200，分别代表短重试时间间隔和次数以及长重试时间间隔和次数，它们的作用和含义在于当通道从running变为retrying状态时，按照这四个参数规定的时间间隔和次数进行通道重新连接的尝试，并且先进行短重试，短重试结束后，再进入长重试。

在设计这四个参数时，要注意以下两点：

1） 要确保短重试+长重试的时间〉故障恢复时间

例如：假设您估计您的系统故障恢复时间为1个小时，则要设置shorttmr*(time of shortrty)+longtmr*(time of shortrty)>2 hours这样，才能保证在故障恢复之后，通道仍然能够自动进行重新连接的尝试。

2） 重试间隔将影响自动恢复的效率

例如：如果您把短重试总时间设定为10分钟，而长重试时间间隔设为1小时，而网络在15分钟后，便已经恢复，可是此时，由于通道已经进入长重试阶段，它将在1个小时之后，才能通过长重试恢复通道的正常运行。相反，也不必把重试间隔设置得太短，应根据需要和用户的实际情况进行适中的设置。

2.3.7 Batch size属性

通道的Batch size(BATCHSZ)值是影响通道性能的一个关键参数。在MQ进行消息传输时，通道对消息的处理也是在同步点的控制之下并具有交易特性的，在以下条件满足时，它将统一提交一批消息：

当发送的消息个数达到BATCHSZ时；或传输队列为空，并且在BATCHINT指定的时间间隔内一直没有消息到达时。

缺省情况下，通道的Batchsz是50，这是一个较为合理和优化的设置。一个小的Batch size值会使每条消息占用大的资源。比如，假设我们在局域网的情况下，Batch size值越大，通道的性能越好。然而，在广域网环境下，要根据网络状况的好坏来设置该参数，若网络状况很差，Batch size值越大，可能会导致通道的性能越差。

2.3.8 NpmSpeed属性

WebSphere MQ的消息分为永久性消息和非永久性消息两种，对于非永久性消息，通道属性NPMSPEED可以设置为FAST和NORMAL，为了提高性能，可以设定该属性为FAST。

2.4 通道通讯优化 2.4.1 选择侦听程序(Listener)的运行方式

MQ的侦听程序有两种配置和启动方式，一种是通过配置/etc/inetd.conf文件选择使用inetd方式, 也可以使用MQ自身提供的runmqlsr程序，所不同的是：runmqlsr 是一个线程应用，所以比inetd需要更少的内存消耗。因此，采用runmqlsr方式可以提高通道相关的性能。

2.4.2 选择通道的运行方式

与侦听程序类似，与MQ通道对应的MCA代理程序也可以有线程和进程两种运行方式，可以通过定义通道的MCATYPE属性来设置通道MCA的运行方式为thread方式。让通道以线程方式运行而非进程方式运行，这样可以减少通道运行的进程个数和消耗的内存资源。

对于以上两点，要注意的是：当通道的连接个数很多时，如在Unix平台上超过500个时，建议MCATYPE和listener采用进程的方式。

2.4.3 设置侦听程序的trusted运行方式

与MQ应用程序类似，MQ的通道侦听程序也有trusted(fastpath)和non trusted(standard)两种运行方式，采用trusted运行方式可以降低CPU和内存消耗。将通道和侦听程序设置为trusted方式运行的方法是通过修改qm.ini配置文件中的MQIBindType参数来实现，即创建或修改qm.ini文件中与Channels相关的小节，例如：

Channels:

MQIBindType=FASTPATH 或者

MQIBindType=STANDARD

其中，FASTPATH表示trusted运行方式，而STANDARD表示非trusted运行方式。

2.4.4 通道的PipeLineLength属性

从MQ版本V5.2开始，MQ提供了一个新的通道参数，即PipeLineLength属性，通过该属性，可以设置MCA采用多个线程的方式来传输消息，从而成为提高通道性能的又一个手段。缺省情况下，该参数数值为1，任何大于1的设置MQ本身都会将其设置为2。

设置PipeLineLength的方法是修改qm.ini文件的Channels一节，如下：

Channels:

PipeLineLength=2

注意，必须在通道两端都进行设置，否则会自动取两者之间的最小值。

2.4.5 设置MaxChannels和MaxActiveChannels属性

    MaxChannels和MaxActiveChannels分别代表队列管理器允许配置的通道的最大个数和允许同时运行的通道的个数，MaxChannels的缺省值是100，MaxActiveChannels的缺省值与MaxChannels相同。如果您的并发通道连接个数超过了100，您需要修改这两个参数。这对于大并发的Client/Server间通讯尤为重要。

2.4.6 使用AdoptNewMCA

在WebSphere MQ的5.2版本以上，新增加了一个控制通道运行的新的参数，既AdoptNewMCA,它可以通过修改qm.ini文件的Channels一节进行修改,如：

Channels:

AdoptNewMCA=ALL

它可以被设置为：NO,SVR,SNDR,RCVR,CLUSRCVR,ALL,FASTPATH等值。当MQ接收到启动通道的请求，但是同时它发现与该通道对应的amqcrsta的进程已经存在，这时，该进程必须首先被停止，然后，通道才能启动。AdoptNewMCA的作用就是停止这种进程，并且为新的通道启动请求启动一个新的进程。

该属性可以将状态处于running状态的接收端通道强行终止，从而使发送端的通道启动或请求操作得以成功。

如果为某一通道指定了AdoptNewMCA的属性，但是新的通道由于"channel is already running"而启动失败，则它可以：

1） 新的通道通知之前的通道停止

2） 如果旧的通道在AdoptNewMCATimeout的时间间隔内没有接受该停止请求，相应的进程（或线程）被kill掉

3） 如果旧的通道经过步骤2仍未终止，则当第二个AdoptNewMCATimeout时间间隔到达时，MQ终止该通道，同时产生"channel in use"的错误。

2.4.7 实现断网续传和故障恢复

WebSphere MQ作为一个消息传输产品，本身是架构在TCP/IP之上的，因此与操作系统或网络底层的TCP/IP特性有着密切的关系，很多情况下我们要借助于修改操作系统的TCP/IP参数，来使它更好地为WebSphere MQ服务，从而更加完善地发挥WebSphere MQ的强大功能。

当我们要在WebSphere MQ的两个队列管理器之间建立通讯时，由于WebSphere MQ的通道是单向的，我们必须要建立两条通道(Chanel)，比如建立两条类型分别为发送(sender)类型和接收(receiver)类型的通道来实现两个WebSphere MQ Server之间的通讯，在通道的两端WebSphere MQ利用MCA(消息通道代理)来管理和监控通道的启停等运行状态，并对通道两端的消息系列号(Message Sequence Number)等进行协同管理，以保证WebSphere MQ对消息的"Once and Once Only"的传输。对WebSphere MQ而言，在其系统配置配置文件mqs.ini文件中，在mqs.ini文件中，包含了对队列管理器的日志大小、通道属性以及通过XA标准与数据库协同工作时的有关参数的设置，除此之外，有一节用于控制有关TCP/IP特性的信息，即：

TCP：

KeepAlive=Yes或

KeepAlive=No

它的作用在于：当设置KeepAlive=Yes时，表示操作系统的TCP/IP参数设置对WebSphere MQ生效。

由于WebSphere MQ接收通道的MCA处于通讯的被动方，它一直等待从发送方传来的消息，因此它不知道什么时候发送方会停止发送消息，也不知道当网络出现故障时，发送方什么时候会从工作状态变为停止状态。这时由于出现网络故障，网络连接被断掉，发送方通道状态会由running状态变为retrying状态，发送方会试图重新建立网络连接，而这时接收方的通道却没有停下来，仍处于一种假"running"的状态，相应的我们会得到一个"Channel is in use"的错误信息，导致发送端想重起却重起不了。出现这一现象的原因是：当发送方MCA启动通道并长时间没有断开连接，这时出现网络故障，TCP/IP的socket连接被破坏，当发送停止通道并重新启动时，它需要建立一个新的socket连接，而接收方仍停留在原来的RECEIVE调用上，它的socket特征与发送方新的socket特征不一致，因此新的socket连接建立失败。

我们可以利用TCP/IP特性来克服这一点，更好地实现断网续传。通常，操作系统的TCP/IP参数的缺省设置是2个小时（常见的操作系统平台如：Windows 2000/NT以及AIX,HP-UX,Sun Solaris，Linux等，缺省设定均为2个小时）即发送KeepAlive探测包的时间是2小时，所以需要2个小时的时间它才会获知网络连接已经断开，这对于我们来说无疑是无法接受的。在这种情况下，我们可以通过配置TCP/IP KeepAlive参数来提高TCP/IP的响应速度，从而实现网络故障时WebSphere MQ能够迅速断开通道连接从而重新启动通道，实现断网续传的强大功能。只有这样，在发送端，MQ的channel才能由running状态变为retrying状态，同时，在接收端，MQ的channel才能由running状态变为not found状态, 这样，在网络或主机重新恢复时，通道才能重新建立起连接，恢复running状态。

要实现上述功能，我们需要作以下两方面的工作：

1）修改WebSphere MQ系统配置文件mqs.ini，增加如下一节：

TCP：

KeepAlive=Yes

目的是使系统的TCP/IP设置对WebSphere MQ生效。

2）修改操作系统的TCP/IP参数；

在不同的系统上，修改TCP/IP参数的方法略有不同，现仅以Windows 2000/NT、RISC6000和HP为例作一简单说明。

• 在Windows NT平台上， 我们利用regedit来修改系统注册表，修改HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Tcpip\Parameters下的以下三个参数：
  KeepAliveInterval,设置其值为1000
  KeepAliveTime,设置其值为300000(单位为毫秒，300000代表5分钟)
  TcpMaxDataRetransmissions,设置其值为5
• 在RISC6000平台上， 用no命令修改如下参数:
  tcp_keepidle保持TCP/IP连接的时间，单位为0.5秒，缺省值为14,400，即两个小时，我们可将它设为5分钟；
  tcp_keepinittcp连接初始timeout值，单位为0.5秒，缺省值为150，我们可将它设为50；
  tcp_keepintvl连接间隔，单位为0.5秒，缺省值为150，我们可将它设为50；
  我们也可以修改/etc/rc.net文件，
  /usr/sbin/no -o tcp_keepidle=240
  /usr/sbin/no -o tcp_keepinit=50
  /usr/sbin/no -o tcp_keepintvl=50
  注意：直接使用命令行修改，在机器重启后，会失效；修改rc.net文件，可以做到永久生效。
• 在HP平台上，
  对于HP-UNIX V10.20及其在此之前的版本，用/usr/contrib/bin nettune命令来修改有关参数；
  对于HP-UNIX V10.30及其以上版本，用/usr/bin/ndd命令来修改有关参数。
• 在SUN Solaris平台上，
  用ndd -set /dev/tcptcp_keepalive_interval NNN命令来修改有关参数,tcp_keepalive_interval的单位为毫秒，缺省值为7200000毫秒，即2个小时。
• 在SCO OpenServer平台上，
  tcp_keepalive 和 tcp_keepidle 相同，其原先默认值为 7200 秒，可设为 600秒。tcp_keepintvl 其原先默认值为 75 秒，可设为15秒。均以"秒"为单位。
  运行命令 ifconfig 命令修改：
  /etc/inconfig tcp_keepidle <value>
  /etc/inconfig tcp_keepintvl <value>
  需要注意的一点是通道两端的KeepAlive参数要保持协调一致，若发送端的KeepAlive值小于接收端的KeepAlive值，则当网络出现故障时，发送端的通道停下来之后，接收端的通道会仍然停不下来。

2.5 通道的维护

通过使用MQSC命令DEFINE来创建通道，DELETE删除通道。用DISPLAY显示通道属性，用ALTER修改属性。注意，通道只有在停止状态下才可以被删除或修改。

例如：

*创建接收端通道(QMA.QMB)

DEFINE CHANNEL(QMA.QMB) CHLTYPE(RCVR)

*创建发送方通道(QMA.QMB)，连接对方的IP地址为192.168.1.100，端口为1415，通道连接传输队列TO.QMB

DEFINE CHANNEL(QMA.QMB) CHLTYPE(SDR) CONNAME(‘192.168.1.100(1415)’) XMTIQ(TO.QMB)

*删除通道(QMA.QMB)

DELETE CHANNEL(QMA.QMB)

*修改通道(QMA.QMB)的批次消息数量为100

ALTER CHANNEL(QMA.QMB) CHLTYPE(SDR) BATCHSZ(100)

*显示通道(QMA.QMB)的断开间隔时间

DISPLAY CHANNEL(QMA.QMB) DISCINT

*显示通道(QMA.QMB)的状态

DISPLAY CHS(QMA.QMB) AL

由于通道是一种特殊的MQ对象，它的某些状态会随着通信环境的改变而变化，比如通道状态、通道流量、通道消息序号等，我们称之为通道的动态信息。MQSC也提供了一些命令用来动态管理通道。

2.5.1 通道start命令

通道的启动可以通过MQSC的start channel命令完成，例如格式为：

START CHANNEL(ChannelName)

也可以在命令行通过runmqchl控制命令完成，两者效果相同，在Windows中还可以用MQ服务配置成自动启动方式。

runmqchl在通道连接的主动方使用，使用时需要指定队列管理器名和通道名。

$runmqchl [-m QMgrName] –c ChannelName

选项-m QMgrName表示队列管理器名，缺省为缺省队列管理器。–c ChannelName示通道.

例如：runmqchl –m QM1 –c QM1.QM2

在Websphere MQ for Windows产品中，可以通过WebSphre MQ服务（本地）工具来进行配置。

2.5.2 通道stop命令

用MQSC命令STOP CHANNEL可以停止通道，停止通道也只有在连接通道的主动方发起才有作用。例如格式为：

STOP CHANNEL(ChannelName)

2.5.3 通道reset命令

通道为传送的每一条消息分配了一个序列号，它会自动累计增值，每传送一条消息，双方的消息序号都会自动加一。这个消息序号在通道中用SEQNUM属性表示，在双方连接通道的时候会约定一个起始值，以后每传递一条消息各自加一。通道的相关属性SEQWRAP表示序号的最大值，缺省最大值为999,999,999。序列号越界后自动归零，从头开始。通道利用消息序号来标识传送和确认的消息。

通常情况下，通道双方的消息序号计数应该是相同的。然而在某些异常情况下，会出现双方序号不一致的情况，这通常是因为通信故障后，双方对前面的某一条（或一批）消息是否发送成功理解不一致。在解决了不确定（In-doubt）的消息后，可以用MQSC命令通过重置消息序号将双方调整到一致。一旦连接断开后，通道重连时双方MCA会将消息序号同步。如果通信异常造成序号不一致，可以在通道发送端用MQSC命令RESET CHANNEL SEQNUM手工将两者同步。

在连接通道的主动方重置消息序号会将双方一起调整，在被动方重置则只设置一端。

RESET CHANNEL(ChannelName) [SEQNUM(number)]

2.5.4 通道resolve命令

发送方和接收方的通道状态中除了SEQNUM（通道消息序号）参数控制消息传递外，还有LUWID参数。LUWID指的消息批次交易号，对于每一批消息发送方都需要收到接收方的确认信息才认为消息完整无误地送达对方，接着产生下一个LUWID并开始下一批消息传送。如果没有收到确认而与接收方失去联系，这时发送方认为这批消息为不确定（In-doubt）状态。

大多数时候，WebSphere MQ会在通道重连时自动解决不确定状态的问题。当然，我们也可以手工解决。事实上，通道的LUWID分成CURLUWID和LSTLUWID两个参数属性，具体工作过程如下：

发送方产生一个批次交易号，设置在CURLUWID并通知接收方

接收方将其设置在CURLUWID

发送方向接收方一条接一条地传送整批消息

接收方在完整地收到消息后，将交易号设置在LSTLUWID，提交整批消息并回送确认信息

发送方在接收确认信息后，将交易号设置在LSTLUWID，提交整批消息

重复上述步骤。

所以，在发送方出现不确定状态时，只需要比较一个发送方的CURLUWID和接收方的LSTLUWID，就可以知道该批消息在接收端是否已经提交，从而在发送方做出相应的动作即可。具体步骤如下：

1）比较双方的LUWID

● 对于不确定（In-doubt）状态的发送端：

DISPLAY CHSTATUS(ChannelName) SAVED CURLUWID

● 对于接收端：

DISPLAY CHSTATUS(ChannelName) SAVED LSTLUWID

2）如果两者相同，说明该批消息在接收端已经完整地收到并提交。在发送端执行：

RESOLVE CHANNEL(ChannelName) ACTION(COMMIT)

3）如果两者不同，说明该批消息在接收端未能完整地收到并提交。在发送端执行：

RESOLVE CHANNEL(ChannelName) ACTION(BACKOUT)

2.5.5 通道ping命令

类似于TCP/IP中的ping命令，MQSC命令中也有对通道的PING，格式如下。其中，DATALEN表示PING数据包的大小，可以用16字节到32,768字节。

PING CHANNEL(ChannelName) [DATALEN(16|integer)]

PING命令可以检查对方的队列管理器或端口监听器是否启动，也可以检查对方的通道定义是否正确。但不检查通道的通性状态。换句话说，PING CHANNEL只检查通道能否连通，而不检查目前是否连通。

3. 附录：MQ对象配置参考

队列管理器QMA和队列管理器QMB是互为双向通讯，它们都分别有本地接收队列，传输队列，死信队列，远程队列，发送通道，接收通道。

队列管理器QMA的对象定义清单：

*定义接收队列QLA

def ql(QLA) maxdepth(10000) defpsist(yes) maxmsgl(1048576) replace

*定义传输队列TO.QMB

def ql(TO.QMB) usage(xmitq) defpsist(yes) maxdepth(10000) maxmsgl(1048576) +

trigger trigtype(first) trigdata(QMA.QMB) initq(system.channel.initq) replace

*定义发送通道QMA.QMB

def chl(QMA.QMB) CHLTYPE(SDR) discint(1800) +

XMITQ(TO.QMB) CONNAME(’11.193.9.74(1415)’) trptype(tcp) +

shortrty(10000) shorttmr(30) longtmr(300) longrty(999999999) +

batchsz(50) replace

*定义接收通道QMA.QMB

def chl(QMB.QMA) CHLTYPE(RCVR) replace

*定义远程队列

def qr(QRB) rname(QLB) rqmname(QMB) xmitq(TO.QMB) defpsist(yes) replace

*定义死信队列

def ql(DEADQ) defpsist(yes) maxdepth(20000) replace

alter qmgr deadq(DEADQ)

*

alter ql(system.cics.initiation.queue) defpsist(yes)

*修改first触发间隔时间

alter qmgr trigint(5000)

队列管理器QMB的对象定义清单：

*定义接收队列QLB

def ql(QLB) maxdepth(10000) defpsist(yes) maxmsgl(1048576) replace

*定义传输队列TO.QMA

def ql(TO.QMA) usage(xmitq) defpsist(yes) maxdepth(10000) maxmsgl(1048576) +

trigger trigtype(first) trigdata(QMB.QMA) initq(system.channel.initq) replace

*定义发送通道QMB.QMA

def chl(QMB.QMA) CHLTYPE(SDR) discint(1800) +

XMITQ(TO.QMA) CONNAME(’11.193.9.73(1415)’) trptype(tcp) +

shortrty(10000) shorttmr(30) longtmr(300) longrty(999999999) +

batchsz(50) replace

*定义接收通道QMA.QMB

def chl(QMA.QMB) CHLTYPE(RCVR) replace

*定义远程队列

def qr(QRA) rname(QLA) rqmname(QMA) xmitq(TO.QMA) defpsist(yes) replace

*定义死信队列

def ql(DEADQ) defpsist(yes) maxdepth(20000) replace

alter qmgr deadq(DEADQ)

*

alter ql(system.cics.initiation.queue) defpsist(yes)

*修改first触发间隔时间

alter qmgr trigint(5000)

WAS开启了全局安全性之后，在停止WAS server时，会要求手动输入password，我们可以采取在soap.client.props（这里只讲默认的SOAP方式）里添加指定用户名和密码的方式。如下图。

这时会面临另外一个问题：密码明文。

WAS提供PropFilePasswordEncoder命令去加密密码。如下图。

这里为了方便，我把soap.client.props放到了跟PropFilePasswordEncoder同一个路径下。

通过以上的方式，我们就可以用最简单的方式去停WAS server了，

C:\Program Files\IBM\WebSphere8\AppServer\profiles\AppSrv01\bin>stopServer.bat s
erver1

关于PropFilePasswordEncoder的用法：

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-iseries&topic=rsec_propfilepwdencoder

worker的工作原理及配置
相对于prefork，worker是2.0 版中全新的支持多线程和多进程混合模型的MPM。由于使用线程来处理，所以可以处理相对海量的请求，而系统资源的开销要小于基于进程的服务器。但是，worker也使用了多进程，每个进程又生成多个线程，以获得基于进程服务器的稳定性。这种MPM的工作方式将是Apache 2.0的发展趋势。
在configure -with-mpm=worker后，进行make编译、make install安装。在缺省生成的
httpd.conf中有以下配置段：
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
worker的工作原理是，由主控制进程生成“StartServers”个子进程，每个子进程中包含固定的ThreadsPerChild线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程，MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数；而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。
MinSpareThreads和MaxSpareThreads的最大缺省值分别是75和250。这两个参数对Apache的性能影响并不大，可以按照实际情况相应调节。
ThreadsPerChild是worker MPM中与性能相关最密切的指令。ThreadsPerChild的最大缺省值是64，如果负载较大，64也是不够的。这时要显式使用ThreadLimit指令，它的最大缺省值是20000。上述两个值位于源码树server/mpm/worker/worker.c中的以下两行：
#define DEFAULT_THREAD_LIMIT 64
#define MAX_THREAD_LIMIT 20000
这两行对应着ThreadsPerChild和ThreadLimit的限制数。最好在configure之前就把64改成所希望的值。注意，不要把这两个值设得太高，超过系统的处理能力，从而因Apache不起动使系统很不稳定。
Worker模式下所能同时处理的请求总数是由子进程总数乘以ThreadsPerChild值决定的，应该大于等于MaxClients。如果负载很大，现有的子进程数不能满足时，控制进程会派生新的子进程。默认最大的子进程总数是16，加大时也需要显式声明ServerLimit（最大值是20000）。这两个值位于源码树server/mpm/worker/worker.c中的以下两行：
#define DEFAULT_SERVER_LIMIT 16
#define MAX_SERVER_LIMIT 20000
需要注意的是，如果显式声明了ServerLimit，那么它乘以ThreadsPerChild的值必须大于等于MaxClients，而且MaxClients必须是ThreadsPerChild的整数倍，否则Apache将会自动调节到一个相应值（可能是个非期望值）。下面是常用worker配置段：
StartServers 3
MaxClients 2000
ServerLimit 25
MinSpareThreads 50
MaxSpareThreads 200
ThreadLimit 200
ThreadsPerChild 100
MaxRequestsPerChild 0
通过上面的叙述，可以了解到Apache 2.0中prefork和worker这两个重要MPM的工作原理，并可根据实际情况来配置Apache相关的核心参数，以获得最大的性能和稳定性。

附：以下个人理解，恐怕有误。

StartServers 3   //apache已启动马上创建3个httpd进程（ps aux可以看到）
MaxClients 2000   //同一时间最大接受2000个请求（其实就是2000个线程）
ServerLimit 25 //apache最大能启动25个进程。
MinSpareThreads 50 //apache至少要有50个空闲线程，用来等待接下来的请求，不满则由进程创建线程
MaxSpareThreads 200 //apache最多能有200个线程，超出了200个线程，则杀死多余的线程
ThreadLimit 200 //限制一个进程最多只能创建200个线程
ThreadsPerChild 100 //设定一个进程固定创建100个线程
MaxRequestsPerChild 10000   //设定当一个进程一共接受过10000此请求之后被杀死。以释放内存。

   从上面的配置我们可以看出，当apache启动时，启动3个httpd进程，每个进程又生成100个线程，但是超过了最大限定的数字，于是杀死100个线程，也就是一个进程。当某个时候有300个请求，目前只有200个线程，于是父进程再创建2个子进程。等请求处理完毕后，在把闲置释放到只剩下200个以内。

WAS 从 V8.0版本开始使用IBM Installation Manager (简称IM) 进行安装。大致安装步骤如下：
1) 下载IM安装包，解压进行安装。
2) 启动IM，进入文件-> 首选项->存储库，点击“添加存储库”，添加WAS V8安装介质所在的存储库url，或点击“浏览”选择本地的存储库。点击 “确定”，在首选项界面上也点击“确定”。
3) 在IM主界面上点击安装。即开始了WAS V8或者相关产品的安装。
WAS V8.0的试用版下载地址是：http://www.ibm.com/developerworks/downloads/ws/wasnetwork/

在这里，您下载到的是IM，安装好这个IM（步骤1）之后，其中首选项菜单里预置了WAS V8试用版安装介质所在的存储库url，也就是说，您不需要做上述步骤2）。 您可以打开“文件-> 首选项->存储库”查看该url，也可以直接进入步骤3），即在IM主界面点击“安装”，进行WAS V8试用版的安装。您需要用IBM ID和密码进行认证。如果您没有IBM ID，可以免费注册一个。

来自：http://www.webspherechina.net/club/thread-50558-1-1.html

下图显示了已通过IM安装好了WAS8试用版

关于IM

WebSphere Application Server Version 8.0 is the first full version to be installed by IBM Installation Manager rather than by the ISMP-based installer, Update Installer, and Installation Factory programs that are used to install and maintain previous versions. Installation Manager is a single installation program that can use remote or local software flat-file repositories to install, modify, or update new WebSphere Application Server products. It determines and shows available packages—including products, fix packs, interim fixes, and so on—checks prerequisites and interdependencies, and installs the selected packages. You also use Installation Manager to easily uninstall the packages that it installed. Important: Do not use the same response files that are used with WebSphere Application Server Version 7.0 or earlier to install or uninstall Version 8.0 and later; use response files that are based on Installation Manager to install, update, or uninstall Version 8.0 and later.

Installation Manager can be invoked through a graphical user interface (GUI) or a command-line interface. You can also create response files in XML and use them to direct the performance of Installation Manager tasks in silent mode.

For more information on using Installation Manager, read the IBM Installation Manager Version 1.4 Information Center

接下来谈谈

using response files

Using Installation Manager, you can work with response files to install the product in a variety of ways. You can record a response file using the GUI as described in the following procedure, or you can generate a new response file by hand or by taking an example and modifying it.

The following is an example of a response file for installing the product.

<?xml version="1.0" encoding="UTF-8"?>
<agent-input clean="true" temporary="true">
<server>
<repository location="http://www.ibm.com/software/repositorymanager/com.ibm.websphere.BASE.v80" />
</server>
<install modify='false'>
<offering id='com.ibm.websphere.BASE.v80'
  profile='IBM WebSphere Application Server V8.0'
  features='core.feature,ejbdeploy,thinclient,embeddablecontainer,com.ibm.sdk.6_32bit' installFixes='none'/>
</install>
<profile id='IBM WebSphere Application Server V8.0'
  installLocation='C:\Program Files\IBM\WebSphere\AppServer'>
<data key='eclipseLocation' value='C:\Program Files\IBM\WebSphere\AppServer'/>
<data key='user.import.profile' value='false'/>
<data key='cic.selector.nl' value='en'/>
</profile>
</agent-input>

详情参见：

http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.installation.base.doc%2Finfo%2Faes%2Fae%2Ftins_installation_dist.html

详情参见如下链接：

http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1109_limh_wasgc
/1109_limh_wasgc.html

2.IBM® WebSphere® Application Server V8 是一个重要版本，它提供了一些引人注目的运行时改进，还提供了一些简便的应用程序开发和部署方法。

EJB 3.1

EJB 3.1 新增了将 EJB 打包成 WAR 文件的功能

Contexts and Dependency Injection for Java (CDI) 1.0

安装

IBM Installation Manager 用于为下列操作提供某种单一的安装技术：

• 安装和卸载产品。
• 更新和回滚修复包和 iFixes。
• 安装和卸载特性包。

节点恢复

addNode 命令的一个新的可选参数 asExisitingNode 可以使得移动或恢复节点变得更轻松。使用这个命令参数时，使用来自节点的 Deployment Manager 的配置来添加节点。因此，节点可以轻松移动到新服务器，如果需要，移动过程中还有一些设置可用来更改主机名。一旦出现硬件故障，节点可以轻松恢复到 Deployment Manager 维护的单元配置中反映的最后配置。

详情参见如下链接：

http://www.ibm.com/developerworks/cn/websphere/techjournal/1106_alcott/1106_alcott.html

通过IBM Http Server（下文称为IHS）静态页面分离技术与利用WebSpere Application Server(下文称为WAS)的动态高速缓存（Dynamic Cache）技术优化访问页面性能。客户端访问静态页面无须与后端数据交互，减少了容器与数据源的压力，从而达到优化系统的性能。

IBM Http Server不但可以作为 WAS 的前一级 Http 请求队列的缓冲,减轻WAS的压力，还可以利用其静态页面分离方案减轻部分压力。在系统的部署或者构建的时候，我们可以把一些非重要的静态页面放在 IHS 中，当客户端发送请求访问该页面资源时，由IHS直接响应请求并将静态页面资源返回客户端，无须再经过WAS，从而达到减轻达到WAS 负担的目的。
除了IHS静态页面分离方案，另外还可以利用WAS的动态高速缓存技术，将J2EE应用中静态的（Html、Flash、Css、Js、Jpg、Gif图片等文件）和动态的（需要与数据库、Web Service等服务交互才能得到的数据）内容缓存到应用服务器的JVM中(如：Jsp、Servlet、*.do等请求)。在访问相关被缓存的资源时，所有的相关输出都可以直接从JVM的内容中获得，而无须再与数据库、Web Service、静态文件等交互，从而有效地提高系统的性能。
IHS分离静态内容方案

整个操作过程主要分3步完成
n 关闭Was的File Serving Servlet服务
n 重新生成插件(Plugin-cfg.xml)
n 修改IHS配置文件并拷贝静态文件到指定的目录
关闭Was的File Serving Servlet服务
1) 在Was中部署的Web应用中分别找到2个在/WEB-INF/ 目录下面的 ibm-web-ext.xmi 文件。
参考路径：
Ø IBM/WebSphere/AppServer/profiles/节点/conf/cell/applications/应用包名/ deployments/应用包名/应用包名/WEB-INF/目录下
Ø IBM/WebSphere/AppServer/profiles/节点/应用安装部署目录/应用包名/应用包名/WEB-INF/目录下
2) 打开 ibm-web-ext.xmi 文件，找到 fileServingEnabled 属性项，把它设为 flase, 默认是ture。找不到该属性项可直接手工添加（fileServingEnabled="false"）。
如：
<?xml version="1.0" encoding="UTF-8"?>
<com.ibm.ejs.models.base.extensions.webappext:WebAppExtension
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.ejs.models.base.extensions.webappext="webappext.xmi" xmi:id="WebAppExtension_1260496854906"
fileServingEnabled="false">
<webApp href="WEB-INF/web.xml#WebApp_1260496854890"/>
<jspAttributes xmi:id="JSPAttribute_1260496854906"
name="reloadEnabled" value="true"/>
<jspAttributes xmi:id="JSPAttribute_1260496854907"
name="reloadInterval" value="10"/>
</com.ibm.ejs.models.base.extensions.webappext:WebAppExtension>
3) 重启Was，重启完校验配置是否生效。访问Web应用中的静态文件，如会报404错误的，这是正常现象，表示Was中的 File Serving servle 服务功能已经被关闭了。
重新生成插件(Plugin-cfg.xml)
Ø 登陆Was控制台，环境->更新全局 Web 服务器插件配置->确定,重新生成插件。
Ø 服务器->Web服务器->选择相应的web服务器->生产播件->传播插件
Ø 检查配置文件是否正取。
打开IHS/Plugins/conf/web服务名/plugin-cfg.xml.找到UriGroup项，检查其配置。如Uri中的配置还是指定为 Name=”/*”，须注释该行配置，否则IHS会将所有的请求都返回给WAS处理，那么所有访问静态内容都会报404错误。可通过手工配置相应无须过滤的Uri。
具体参考配置如下：
<UriGroup Name="default_host_kpiCluster_URIs">
<!–<Uri AffinityCookie="JSESSIONID"
AffinityURLIdentifier="jsessionid" Name="/*"/> –>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.do"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/>
</UriGroup>
修改IHS配置文件并拷贝静态文件到指定的目录
1) 在IHS的默认路径，打开 \IBM HTTP Server\conf\http.conf文件，找到如下配置：
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "D:\IBM\HTTPServer/htdocs/en_US"
#
# This should be changed to whatever you set DocumentRoot to.
#
<Directory "D:\IBM\HTTPServer/htdocs/en_US">
可将 D:\IBM\HTTPServer/htdocs/en_US 设置为新的目录，自定义新的静态页面目录。
我们将非重要的静态文件放到E:\PageFiles\2009-12-11\目录下，配置如下：
DocumentRoot "E:\PageFiles\2009-12-11"
<Directory " E:\PageFiles\2009-12-11">
2) 把应用中的静态文件拷到 上述在Httpd.conf配置文件定义好的路径中去。
最后可根据上面的配置，将静态文件都是从Was应用中拷贝到E:\PageFiles\2009-12-11\目录中。
3) 重新启动IHS
通过页面再次访问静态页面，此时不会再出现404错误了，IHS接到请求访问静态页面内容时，会直接读取E:\PageFile\2009-12-11\返回页面请求，通过该配置可以进一步减轻Was的压力。
启用WAS动态高速缓存

启用动态高速缓存服务同样也分为3步
n 在WAS控制台上启用动态高速缓存服务
n 为应用服务器配置 Servlet 高速缓存
n cachespec.xml配置文件
在WAS控制台上启用动态高速缓存服务：
1) 登录Was的管理控制台
2) 在管理控制台中，启用“服务器->应用程序服务器->Server1->容器服务->动态高速缓存服务”
(勾上‘在服务器启动时启用服务’)
3) 确定并保存配置
为应用服务器配置 Servlet 高速缓存：
1) 在管理控制台中，启用“服务器->应用程序服务器->Server1->Web容器设置->Web容器-> 启用servlet 高速缓存
(勾上‘启用servlet 高速缓存’)
2) 确定并保存配置
cachespec.xml配置文件
1) 在应用目录下WEB-INF/下增加cachespec.xml配置文件，通过该文件指定缓存对象。
内容如下：注意红色部分，要正确指定cachespec.dtd文件位置，一般情况下是在/IBM/WebSphere/Appserver/properties目录下。
<?xml version="1.0" ?>
<!DOCTYPE cache SYSTEM "D:\IBM\WebSphere\AppServer\properties\cachespec.dtd">
<cache>
<cache-entry>
<class>servlet</class>
<name>index.jsp</name>
<cache-id>
<component id="*" type="parameter">
<required>false</required>
</component>
<component id="" type="pathinfo">
<required>false</required>
</component>
<component id="host" type="header">
<required>false</required>
</component>
<timeout>180</timeout>
</cache-id>
</cache-entry>
</cache>
2) 在完成前三步后，在服务器上安装Cache Monitor组件，来监控刚才配置的动态高速缓存（Dynamic Cache）是否成功运行。
发布IBM/WebSphere/AppServer/installableApps/CacheMonitor.ear,并且将该应用与要业务应用部署在用一个Server下。
3) 部署完毕后，重启整个WAS。
4) 测试校验部署是否生效。
分别访问:
Ø http://127.0.0.1/index.jsp
Ø http://127.0.0.1/index.jsp?123
通过访问 http://127.0.0.1/cachemonitor 就可以查看到index.jsp已进行了缓存
如图所示：
以上的两种技术一种是基于WEB服务器一级别的优化，另一种则是基于Websphere应用服务器上的优化，合理的使用两种技术，可更有效的帮助应用系统提高性能。
虽然在 WAS V6 以上的版本中，Web Container 对于 Http 请求采用了非阻塞I/O 方式，使得IHS 的这一功能作用已经非常弱化，但在大并发访问的情况下，还是建议大家使用IHS+WAS架构，使用IHS缓冲客户端请求与并且利用其得静态页面技术，直接返回静态资源，减轻应用服务器压力；开启Was动态高速缓存，缓存一些变动较少的Jsp、Servlet等资源，进一步有效的优化系统的性能。分别将IHS与WAS 部署到两台物理主机上，可以让在系统在性能扩展上更加灵活，利用垂直扩展优化可更有效的提高系统的性能。

Question

In WebSphere® Process Server V6, what data and information is stored in the wstemp directory of a custom or deployment manager profile, and what is it used for?

Cause

The wstemp directory of the deployment manager profile includes many files and directories. These take up a lot of space in the file system.

Answer

Each custom or deployment manager profile stores temporary data in the appropriate directory:

<profileRoot>/<profileName>/wstemp
This directory is primarily used by the WebSphere Application Server workspace management component to store temporary session data. After you log in to the administrative console, a new session for the specified user is created to reflect the current operations and configurations. If administrative security is enabled and configured, you must specify a valid user name and password; if you do not, any user name can be used to log in. Depending on the login method, a new subdirectory is created for the user session:
Anonymous login
<profileRoot>/<profileName>/wstemp/anonymous<ID>
Login using a specific user name (and password)
<profileRoot>/<profileName>/wstemp/<userNameHashCode>
The temporary session data is needed as long as a user is logged in. You may observe a high number of created directories in the temporary directory even if no user is logged in. The session directories are deleted by default after a user correctly logs out of the administrative console. If a user closes the Web browser instead of logging out of the administrative console, the directories remain in the file system.
You can safely delete the contents of the temporary directory to free space on the file system. Shut down the deployment manager before deleting the content to ensure that no user is logged in so no open or active sessions become corrupted.
Hint: The temporary directory includes a file named preferences.xml for each user, which stores the console preferences that are configured by that user. If you delete the preferences.xml for a specific user, the administrative console loses the configured preferences, so the user must reconfigure them with the next login. To clean the temporary directory of unnecessary data but keep the preferences configuration file, each user must log out of the administrative console before closing the Web browser.

Related information

Problem with workspace directories
How does wstemp directory work
Clearing wstemp will delete console preferences
Logs and temporary files that can safely be removed

任何一种软件，都会存在一定的系统管理工作，WebSphere MQ也不例外，在使用WebSphere MQ（以下简称MQ）时，我们可能会由于配置的原因或者由于系统的原因，也可能由于MQ本身的原因，而遇到MQ运行过程中的一些故障和问题，如何能够快速地定位这些问题，分析问题发生的原因，进而快速地解决问题，恢复系统正常运行呢？这需要一定的经验积累和技巧，本文将对这方面给出一些简单的提示和方法。

其实，MQ的故障分析手段很多，例如MQ的错误日志即是一种简单易行、快速有效的手段，通过查看错误日志往往能一针见血地迅速解决问题，另外MQ还提供了其它一些手段，如通过作 trace 和 FFST (First Failure support technology) 等途径，来追踪和记录错误信息，从而解决问题。

作为一个跨平台的中间件产品，MQ在各个平台上的系统管理方法也有极大的相似之处，尤其在AIX，SUN，HP-UNIX等Unix平台和WindowsNT/2000平台上，本文将以MQ for Windows NT/2000 为例，帮助您分析和定位产品运行过程中可能发生的问题，并给出查找问题的办法，帮助您分析问题产生的可能原因，从而给出解决问题的途径。

在分析故障原因时，通常可从一个或一系列症状入手，对它们进行跟踪以发现问题发生的原因。然而，诊断问题不是解决问题。但是，问题诊断的过程常使你能够解决问题。例如，如果你发现引起问题的原因是应用程序中的一个错误，你就可以通过改正该错误来解决问题。如果在确定了问题的原因并采取了相应措施后，您仍不能解决问题，您可以和IBM支持中心联系以帮助您解决问题。

MQ作为一个通讯中间件产品，它的运行故障概括而言主要与网络、MQ本身以及客户应用三个方面有关，通常出现故障时，主要要从这三方面考虑，当然还需要排除和考虑其它一些额外因素，例如，是否别的应用出现异常，把内存等资源耗尽从而导致了MQ的运行失败等等。

MQ为我们提供了丰富的故障分析手段，例如，MQ的系统管理命令，MQ的各种类型的错误日志，MQ的trace, FFST等。以下本篇将从错误日志、常见故障分析等几方面探讨一下MQ的故障分析技巧。首先我们讨论对于发现问题、解决问题十分重要，也非常奏效的MQ提供的错误日志手段，然后讨论在MQ运行过程中可能会出现的问题，并给出基本的解决方案，最后简单讨论MQ提供的trace和 FFST(First Failure support technology) 两种错误分析手段。

1 错误日志分析

当MQ运行过程中，出现问题时，我们第一个应该采取的行动应该是察看MQ的错误日志。注意，在这里，不要将MQ系统的数据日志和错误日志相混淆。MQ的数据日志包含了"data"和"action"两部分，在NT/2000平台上位于/mqm/log下（假设MQSeries产品安装目录为C:\MQM下），是对MQ的消息数据以及用户对MQ的操作的纪录，是用于数据备份和系统恢复时使用的，也是数据不丢失、不重复的保障。而MQ的错误日志是对MQ系统运行过程中出现错误的纪录，它是我们查找错误原因的最简单快捷，最方便有效的手段。用户一定要掌握这一方法，养成察看错误日志的良好习惯。

MQ在各种层次上，为用户提供了丰富的日志文件，这些日志文件包含了所有被启动的队列管理器、有关对MQ的队列管理器操作、以及被启动的通道的相关信息，当队列管理器和通道等运行时，有关信息包括出现异常情况时的信息都将在日志文件中有所体现。

在Windows NT/2000环境中，各个日志文件的位置如下(假设MQSeries产品安装目录为C:\MQM下)：

若队列管理器名称已知，并且处于运行状态，错误日志位于：

c:\mqm\qmgr\QMgrName\errors
    

若队列管理器不处于运行状态，则错误日志位于：

c:\mqm\qmgrs\@SYSTEM\errors
    

若错误与系统有关，则错误日志位于：

c:\mqm\errors
    

若错误与MQ客户端程序有关，则错误日志位于客户机的根目录下：

c:\mqm\errors
    

另外，对于MQ for Windows NT/2000平台, 错误信息也会被加在操作系统的Application Log中，通过NT/2000操作系统提供的事件日志也可以检测和察看到。

1.1 日志文件

在MQ产品安装时，在qmgrs路径下会建立@SYSTEM的子目录，在errors子目录下会产生三个日志文件：

   AMQERR01.LOG
   AMQERR02.LOG
   AMQERR03.LOG

    

当你建立了队列管理器以后，该队列管理器所需的日志文件随之产生。在mqm\qmgr\QMgrName\errors子目录下会产生三个日志文件：

   AMQERR01.LOG
   AMQERR02.LOG
   AMQERR03.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都会返回一个Completion Code和Reason Code，通过MQI返回码Reason Code，可以在API一层，确定错误原因，Reason Code代表的含义可以参考编程手册，或者从cmqc.h头文件中获得。如：RC2035，代表没有操作权限；RC2085，表示没有该对象；RC2080，表示应用程序给出的buffer小于消息的实际大小等。
• 问题能再现吗？
• 从最近一次成功运行以来，是否在某些地方作过改动？
• 在此之前，应用是否运行成功？
• 网络是否连接正常？
• 问题是否总在每天的某一固定时刻发生？

2.2 深入分析

如果初步分析无法解决问题，您必须更进一步查找原因，您可以近一步考虑如下问题：

2.2.1 与队列相关的问题

1) 队列状态是否正常？

• 用DISPLAY QUEUE命令查看队列的各项状态
• 用得到的队列信息进一步查看：
  
  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状态；而在异常情况下，比如网络连接有问题、通道定义不正确或通道两端的消息序列号(Message Sequence Number)不匹配等，通道即进入retrying的状态，它会根据通道定义中short retry和long retry的次数和时间间隔依次进行short retry和long retry，若不成功，则通道无法正常启动。

2) 消息序列号(Message Sequence Number)

消息序列号是保证MQ消息传输不丢失、不复传的一个重要机制。消息序列号由发送通道分配，是通道的一个永久属性，每当发送一条消息，消息序列号就加一，正常情况下，通道两端的消息序列号或者相等或者相差为一，通道才能正常启动。

通道状态异常时应采取的措施：

1) 查看网络连接是否畅通MQ的通讯是建立在系统网络运行正常的基础之上的，当通道不通时，要首先检查网络连接是否正常。您可以使用操作系统ping命令，也可以采用ftp方式，在两个主机之间尝试进行数据传输，以判断网络是否正常。

2)查看通道定义是否正确通道所使用的传输队列定义是否正确，通道两端的定义是否匹配，如两条通道最大传输的消息长度，Message sequence number wrap是否一致。若不一致，要重新定义通道，可使用MQSC命令DEFINE CHANNEL命令。

3)查看通道的状态

1. 用以下命令来判断通道状态：
   
   dis chstatus(ChannelName)或dis chs(ChannelName)

   其中，ChannelName代表通道的名称，该命令支持通配符，可用dis chs(*)来查看所有通道的状态，

2. 当通道无法正常启动时，必须重新启动通道，可使用MQ的控制命令runmqchl命令，或MQSC命令START CHANNEL来启动通道。
   
   注意：如果通道的接收方状态处于STOPPED状态，必须用start chl(ReceiverChl)来重置它的状态，注意，这并不意味着启动了通道，欲启动通道，必须从发送端来启动。
3. 如果通道处于可疑(in-doubt)状态，则通道启动阶段的互相同步工作无法完成，也会导致通道无法启动。解决方案是：用Resolve Channel命令来确定通道状态；Resolve Channel命令带有两个参数：COMMIT和BACKOUT，用COMMIT参数将传输队列中的消息删除，用BACKOUT参数将传输队列中的消息重新恢复。

4) 查看操作系统、MQ的TCP/IP参数是否设置成功以及runmqchi进程是否处于运行状态

如果您的通道在网络出现异常或对方队列管理器重启后，MQ通讯不能正常恢复，则您要检查您的操作系统的keepidle的TCP/IP相关参数是否设置成功并且生效，同时您要检查队列管理器的属性TCP: KeepAlive是否设置为Yes，另外，您的runmqchi进程是否处于运行状态。

注意：上述三者共同作用，才能保证MQ通道的正常恢复，缺一不可。

5）查看通道的当前消息序列号

用dis chstatus(ChannelName)或dis chs(ChannelName)查看通道的当前一些属性值，在通道的属性值中，current sequence number代表通道当前的消息序列号值，若消息序列号不一致，则可用MQSC命令RESET CHANNEL命令来将消息序列号重新置1。

注意：一般情况下，只有当某一方MQ系统重新安装，队列管理器重建，或人为操作时，才会使通道的消息序列号变为1。

6) 查看错误日志

关于MQ提供的错误日志之前已经作过较为详细的介绍，错误日志是出现异常情况时，系统管理员查找原因时要最先考虑也最为简洁奏效的办法。通道错误日志中的错误信息，往往能很快解决问题。

通常从以上几方面考虑，通道问题都能迎刃而解。

2.2.3 死信队列

如果由于某种原因，消息不能被正常发送，它会被送到死信队列中。你可以用MQSC目录DISPLAY QUEUE来查看死信队列的深度，若队列中有消息，可利用应用程序浏览消息的内容，来确定消息被放入死信队列的原因，从而确定如何处理死信中的消息。消息有可能出现在本地的队列中，也有可能出现在目的地的死信队列中。若发生前一种情况，说明本地某有正确的路由途径，可以使消息继续下传；若发生后一种情况，说明目的地一端所指定的目的队列不存在。

2.2.4 配置文件

对于每一个队列管理器而言，都有一个名为qm.ini的配置文件，如果该配置文件被误删除，会导致"queue manager unavailable"类型的错误。在Windows NT/2000平台上，该配置文件以注册表方式存在，可以使用MQ提供的图形界面进行修改。注意：对qm.ini和队列管理器属性的修改，必须在队列管理器重新启动之后才能生效。

2.2.5 数据日志

前面曾经提到MQ的数据日志，一般情况下，中国用户大多采用循环日志，我们建议您在估算消息容量之后，确定适当的日志大小和个数。如果，在运行过程中，出现了日志写满的情况，MQ也无法正常运行，您可以采取修改qm.ini配置文件的方法，加大日志大小和个数。

2.3 查看系统及应用的运行情况

若从上述两个方面都没有解决问题，最后您就要从系统和应用的角度去进一步分析问题了，比如，您可查看您的系统运行速度是否正常，系统资源是否耗尽等，从而确认是否系统问题影响了MQ的正常运行。

回页首

3 Trace

错误跟踪也是一种跟踪故障的手段，在MQ for Windows NT/2000环境中，我们可以用"strmqtrc"命令来追踪问题的发生原因。

Trace文件除特殊指定，一般放在\mqmwork\errors目录下，文件的命名规律是：AMQppppp.TRC

(注：ppppp是产生trace的进程标识符(PID))。

注意：启动trace跟踪，会影响系统的性能，所以在生产环境中要慎重使用。Trace文件的内容，用户是无法分析和读懂的，要由IBM实验室进行分析。

回页首

4 FFST(First Failure support technology)

在WindowsNT环境中，FFST消息文件位于c:\mqm\errors目录下。这些错误一般较为严重，一般表现为系统错误或MQ内部错误。

FFST文件的命名规则为：AMQnnnnn.mm.FDC，其中

          nnnnn-报告错误的进程标识符(PID)
        mm-序列号，一般为0

        

在FDC文件中，对我们有帮助的是它的开始部分，我们可以参考它的ErrorCode, Probe Type, Probe Description部分的内容来分析原因。它的主要部分也是需要由IBM试验室来分析的，IBM借助MQM Function Stack和MQM Trace History来分析故障原因。

以上，我们初步讨论了有关MQSeries故障分析的一些方法和技巧，希望对大家有所帮助。

据我所知，是有两种的方式来查看queue的content.
Prepare:
假设queue的名字叫做local.queue, queue manager的名字叫做 test.queue.manager，mq安装在/opt/mqm下.
1.先确定queue的长度不是0.
$runmqsc test.queue.manager
dis ql(‘local.queue’) curdepth
     2 : dis ql(‘local.queue’) curdepth
AMQ8409: Display Queue details.
   QUEUE(local.queue)    CURDEPTH(1)
如上所示，queue里面是有一个message的，因为curdepth的长度为1.

2.查看queue的message的内容
第一种方式：使用/opt/mqm/samp/bin/amqsget
第二种方式：使用/opt/mqm/samp/bin/amqsbcg
共同点:
都是在命令后面先跟queue的名字，然后再跟queue manager的名字,如下
/opt/mqm/samp/bin/amqsget local.queue test.queue.manager
区别是：
前者只能查看短长度的message，并且会把message取出（还不是太确定后者）；遇到长度稍微长一点的就会发出2080的error code.
$/opt/mqm/samp/bin/amqsget local.queue test.queue.manager
Sample AMQSGET0 start
MQGET ended with reason code 2080
Sample AMQSGET0 end
而后者则没有这个限制；但是amqsbcg显示的message很奇特，连二进制的都同时显示
$/opt/mqm/samp/bin/amqsbcg local.queue test.queue.manager
………….
………………
00000000: 5246 4820 0000 0002 0000 00BC 0000 0111 ‘RFH …………’
00000010: 0000 04B8 2020 2020 2020 2020 0000 0000 ‘….        ….’
00000020: 0000 04B8 0000 0020 3C6D 6364 3E3C 4D73 ‘……. <mcd><Ms’
00000030: 643E 6A6D 735F 6279 7465 733C 2F4D 7364 ‘d>jms_bytes</Msd’
00000040: 3E3C 2F6D 6364 3E20 0000 003C 3C6A 6D73 ‘></mcd> …<<jms’
…………………
…………………
The end.

配置WAS的standalone LDAP加密时，选择安装了openldap。

下载的openldap版本：openldap-2.4.23

问题：

在./configure时，报checking if Berkeley DB version supported by BDB/HDB backends… no
configure: error: BerkeleyDB version incompatible with BDB/HDB backends

需要先安装BerkeleyDB，下载地址：

http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html

我最先下载的是提供的最新的版本：db-5.1.25.NC.zip

安装步骤：

unzip db-5.1.25.NC.zip  解压，然后cd build_unix/ ，再运行../dist/configure ， 最后，运行make, make install安装。默认的安装在/usr/local， 可以通过 ../dist/configure  –prefix=你的路径，来改变安装路径。

安装好db-5.1.25.NC.zip后，发现对openldap进行configure时，还是报错：

configure: error: BDB/HDB: BerkeleyDB not available

解决办法：

尝试了网上很多办法，还是不行。决定换一个BerkeleyDB的版本试试。

于是重新下载了：db-4.7.25.NC.zip

重新安装好BerkeleyDB后，需要添加一些环境变量，见以下粗体部分：

[root@mylinux openldap-2.4.23]# env

LDFLAGS=-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -R/usr/local/BerkeleyDB.4.7/lib

HOSTNAME=mylinux

TERM=vt100

SHELL=/bin/bash

HISTSIZE=1000

CPPFLAGS=-I/usr/local/BerkeleyDB.4.7/include

SSH_CLIENT=::ffff:192.168.0.10 3336 22

OLDPWD=/apps/openldap

SSH_TTY=/dev/pts/2

USER=root

LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.7/lib

======================================================

最后，进行openldap的安装

1、[root@mylinux openldap-2.4.23]# ./configure

….

….

….

Making servers/slapd/overlays/statover.c

Add syncprov …

Please run “make depend” to build dependencies

[root@mylinux openldap-2.4.23]#

看到“Please run “make depend” to build dependencies”说明configure完毕。

2、[root@mylinux openldap-2.4.23]# make depend

Making depend in /apps/openldap/openldap-2.4.23

Entering subdirectory include

make[1]: Entering directory `/apps/openldap/openldap-2.4.23/include’

Making ldap_config.h

make[1]: Leaving directory `/apps/openldap/openldap-2.4.23/include’

….

….

….

Entering subdirectory man5

make[3]: Entering directory `/apps/openldap/openldap-2.4.23/doc/man/man5′

make[3]: Nothing to be done for `depend’.

make[3]: Leaving directory `/apps/openldap/openldap-2.4.23/doc/man/man5′

Entering subdirectory man8

make[3]: Entering directory `/apps/openldap/openldap-2.4.23/doc/man/man8′

make[3]: Nothing to be done for `depend’.

make[3]: Leaving directory `/apps/openldap/openldap-2.4.23/doc/man/man8′

make[2]: Leaving directory `/apps/openldap/openldap-2.4.23/doc/man’

make[1]: Leaving directory `/apps/openldap/openldap-2.4.23/doc’

3、[root@mylinux openldap-2.4.23]# make

……………………….

……………………….

done

make[3]: Leaving directory `/apps/openldap/openldap-2.4.23/doc/man/man8′

make[2]: Leaving directory `/apps/openldap/openldap-2.4.23/doc/man’

make[1]: Leaving directory `/apps/openldap/openldap-2.4.23/doc’

4、[root@mylinux openldap-2.4.23]# make test

5、[root@mylinux openldap-2.4.23]# make install

安装完成。配置文件的路径在：/usr/local/etc/openldap

最后启动服务：

到路径/usr/local/libexec下

[root@mylinux libexec]# ./slapd

[root@mylinux libexec]# ps -ef|grep slapd |grep -v grep

root 5771 1 0 18:41 ? 00:00:00 ./slapd