由于线上服务端程序，需要大量写入日志，将来入数据库库，以便做数据分析或者对账之用，可是发现日志打开后服务器变慢了，对外并发响应数量也减少了。于是分析了下日志写入函数fprintf。其写日志文件的顺序是：程序写入用户地址空间?内核从用户地址空间缓冲区复制到内核文件缓冲区?内核文件缓冲区满的情况下再放入内核io队列，等待写入到硬盘上。写文件其实不是直接写到硬盘，那样的话一堆程序都同时并发往硬盘上写，硬盘能累吐血。所以文件其实是先写到内存，满员后再写到硬盘，当然这是内核完成的，我们用户程序只要使用系统调用就行了。这样可以减少写硬盘的次数，一次批量多写些内容进去。
一个程序使用系统调用的次数会很大程度上影响系统的性能,因为在执行系统时，会从用户代码切换执行内核代码，然后返回用户代码。优化手段就是尽量减少系统调用次数。
以上这种缓存的思想是很OK的，那么我们的问题在哪里呢？我们的问题其实就是一次性写入的日志很大，通常会超过系统默认的用户地址空间文件缓冲区大小4096字节，刚好就是一个页的大小，应该是为了方便拷贝到内核而设的单位，我们往往一行日志就写了5000多字节，有的甚至1M字节。所以每次写一行日志都会触发系统调用。而我们的服务器程序写日志很频繁，每秒都有几次写这种大型日志的操作，写小日志的操作就更多了。当然可以分不同的文件写到多个日志文件中，缓解单个文件缓冲区的压力，不过这好像么有治本。
在服务器设计上的思想，我是尽可能的用空间换时间，因为用户很挑剔啊，时间上人家可不愿意多等几秒。当然不要无限制的滥用空间，内存和硬盘也很宝贵的。
我们的办法就是在写日志文件的时候，使用setvbuf函数设置自己的缓冲区，尽量在内存够用的情况下，设置大些。我设置了10*4096个字节，这样fprintf函数内部使用系统调用的频率就少了，减少了不少次从用户态拷贝小数据到内核态转换的时间开销，转为积累大数据，一次性拷贝，只一次系统调用就搞定。接下来看示例
调大缓冲区
#include &stdio.h&
#include &sys/stat.h&
#include &sys/time.h&
#define BUF_SIZE 40960
#define LOOP_CNT 1000000
int main ()
int i = 0;
struct timeval start,
char test_fmt[4108];
for(i = 0; i & 4108; i++){
test_fmt[i] = 'A';
printf("循环%d条，数据总量%ld：\n", LOOP_CNT, (long)LOOP_CNT* 4108);
stat("1.txt", &sysbuf);
printf("系统默认文件缓冲区大小 = %d byte,总共%d块\n", (int)sysbuf.st_blksize, (int)sysbuf.st_blocks);
pFile=fopen ("1.txt","w");
gettimeofday(&start,NULL);
for (i = 0; i & LOOP_CNT; i++){
fprintf(pFile, test_fmt, i);
fclose (pFile);
gettimeofday(&end,NULL);
timeuse = 1000000*(end.tv_sec - start.tv_sec) + end.tv_usec - start.tv_
timeuse /= 1000000;
printf("默认缓冲区写文件，用时:%f\n", timeuse);
#include &stdio.h&
#include &sys/stat.h&
#include &sys/time.h&
#define BUF_SIZE 40960
#define LOOP_CNT 1000000
int main ()
int i = 0;
struct timeval start,
char test_fmt[4108];
for(i = 0; i & 4108; i++){
test_fmt[i] = 'A';
printf("循环%d条，数据总量%ld：\n", LOOP_CNT, (long)LOOP_CNT* 4108);
FILE *pFile1;
pFile1=fopen ("2.txt","w");
char buf[BUF_SIZE];
setvbuf ( pFile1 , buf, _IOFBF , BUF_SIZE );
printf("自定义缓冲区 = %d byte\n", BUF_SIZE);
gettimeofday(&start,NULL);
for (i = 0; i & LOOP_CNT; i++){
fprintf(pFile1, test_fmt, i);
fclose (pFile1);
gettimeofday(&end,NULL);
timeuse = 1000000*(end.tv_sec - start.tv_sec) + end.tv_usec - start.tv_
timeuse /= 1000000;
printf("自定义缓冲区写文件，用时:%f\n", timeuse);
在一个5400转硬盘的虚拟机上，分别编译运行，查看结果，其中st_blocks代表该文件使用了多少个块。
一开始测试我犯了个严重的错误，就是将两段代码编译好的程序一起运行，或者两次运行间隔时间不长。后来通过在windows的资源管理器中查看实时磁盘IO，发现写入1.txt的程序虽然已经退出了，但是磁盘还在写入，说明这会是内核在往磁盘中写入呢。而我此时启动另一个测试程序对2.txt做写入操作，会响测试1.txt效果，应该等1.txt完全写入完成，磁盘io不再进行时候再启动对2.txt的操作。
循环10000条，数据总量：
系统默认文件缓冲区大小 = 4096 byte,总共802344块
默认缓冲区写文件，用时:0.468300
循环10000条，数据总量：
自定义缓冲区 = 40960 byte
自定义缓冲区写文件，用时:0.155844
循环100000条，数据总量：
系统默认文件缓冲区大小 = 4096 byte,总共8023438块
默认缓冲区写文件，用时:4.686463
循环100000条，数据总量：
自定义缓冲区 = 40960 byte
自定义缓冲区写文件，用时:1.543402
循环1000000条，数据总量：
系统默认文件缓冲区大小 = 4096 byte,总共2642816块
默认缓冲区写文件，用时:47.181843
循环1000000条，数据总量：
自定义缓冲区 = 40960 byte
自定义缓冲区写文件，用时:28.394735
在写入100000条之前，还有着2倍多的速率差异。
等到写入次数达到1000000条的时候，两者的时间差缩小到了1倍以内，此时的日志文件4.16G。再加大测试的话，内核的IO队列该不够用。
在windows下查看了下虚拟机的写入速率，依然自定义缓存方式要快一些，以下是速率峰值时候的截图
1.用系统默认缓存
最高到74M/s
2.自定义缓存峰值
最高到115M/s
从每次测试的结果看，自定义缓冲区后，写入相同字节的内容，自定义缓冲区明显要比系统默认少一倍以上的时间。当然这是测试，实际项目可根据情况自行调节缓冲区大小。
不过这样做的坏处显而易见，断电就抓瞎了，大量的的缓存还没写到磁盘呢！
调等缓冲区
当然，我们还要测试下设置成和系统默认4096，也就是一个页大小的单位
循环1000000条，数据总量：
系统默认文件缓冲区大小 = 4096 byte,总共块
默认缓冲区写文件，用时:48.648003
循环1000000条，数据总量：
自定义缓冲区 = 4096 byte
自定义缓冲区写文件，用时:49.252640
用时几乎相当，还多了1秒，呵呵。
调小缓冲区
再看看，缩小缓冲区的结果，设为1024字节
循环1000000条，数据总量：
系统默认文件缓冲区大小 = 4096 byte,总共8023438块
默认缓冲区写文件，用时:49.945450
循环1000000条，数据总量：
自定义缓冲区 = 1024 byte
自定义缓冲区写文件，用时:102.239960
这次看到缓冲区缩小后，明显用时更多了，竟然超过1倍多的时间。
FILE结构里本身带有一个缓冲。而内核在操作IO的时候会还有一个缓冲区，内核将缓冲区写到磁盘也不是直接写，而是放到其IO队列中等待写入。加大文件缓冲区，也只是加大了用户态的缓冲区，而内核态缓冲区是没有变的，所以当用户态缓冲区超过4096一个页大小的时候，它从用户地址空间拷贝到内核地址空间时候，应该是切分了好几页，分别加入内核IO的队列中，准备写入到磁盘上。
创建于深圳腾讯，更新于杭州。
C语言文件读写操作中缓冲区问题和setbuf函数详解
C语言的setvbuf函数：设置文件流的缓冲区
设置SecureCRT会话的缓冲区大小
调大预读缓冲区大小来提高性能
45 C语言缓冲区（缓存）详解
没有更多推荐了，sql&server事务日志——事务日志在修改数据时的操作
Server的数据库都会按照其修改数据(insert,update,delete)的顺序将对应的日志记录到日志文件.SQL
Server使用了Write-Ahead
logging技术来保证了事务日志的原子性和持久性.而这项技术不仅仅保证了ACID中的原子性(A)和持久性(D),还大大减少了IO操作，把对数据的修改提交到磁盘的工作交给lazy-writer和checkpoint.本文主要讲述了SQL
Server修改数据时的过程以及相关的技术。
预写式日志（Write-Ahead Logging (WAL)）
Server使用了WAL来确保了事务的原子性和持久性.实际上，不光是SQL
Server,基本上主流的关系数据库包括oracle,mysql,db2都使用了WAL技术.
WAL的核心思想是:在数据写入到数据库之前，先写入到日志.
因为对于数据的每笔修改都记录在日志中，所以将对于数据的修改实时写入到磁盘并没有太大意义，即使当SQL
Server发生意外崩溃时，在恢复(recovery)过程中那些不该写入已经写入到磁盘的数据会被回滚(RollBack),而那些应该写入磁盘却没有写入的数据会被重做(Redo)。
但WAL不仅仅是保证了原子性和持久性。还会提高性能.
硬盘是通过旋转来读取数据,通过WAL技术，每次提交的修改数据的事务并不会马上反映到数据库中，而是先记录到日志.在随后的CeckPoint和lazy
Writer中一并提交,如果没有WAL技术则需要每次提交数据时写入数据库:
而使用WAL合并写入，会大大减少磁盘IO：
也许你会有疑问，那每次对于修改的数据还是会写入日志文件.同样消耗磁盘IO。每一笔写入日志的记录都是按照先后顺序，给定顺序编号的LSN进行写入的，日志只会写入到日志文件的逻辑末端。而不像数据那样，可能会写到磁盘的各个地方.所以，写入日志的开销会比写入数据的开销小很多。
SQL Server修改数据的步骤
Server对于数据的修改,会分为以下几个步骤顺序执行:
1.在SQL Server的缓冲区的日志中写入”Begin
Tran”记录
2.在SQL Server的缓冲区的日志页写入要修改的信息
3.在SQL Server的缓冲区将要修改的数据写入数据页
Server的缓冲区的日志中写入”Commit”记录
5.将缓冲区的日志写入日志文件
6.发送确认信息(ACK)到客户端(SMSS,ODBC等）
可以看到,事务日志并不是一步步写入磁盘.而是首先写入缓冲区后，一次性写入日志到磁盘.这样既能在日志写入磁盘这块减少IO，还能保证日志LSN的顺序.
上面的步骤可以看出，即使事务已经到了Commit阶段，也仅仅只是把缓冲区的日志页写入日志，并没有把数据写入数据库.那将要修改的数据页写入数据库是在何时发生的呢?
Lazy Writer和CheckPoint
上面提到，SQL
Server修改数据的步骤中并没有包含将数据实际写入到磁盘的过程.实际上，将缓冲区内的页写入到磁盘是通过两个过程中的一个实现：
这两个过程分别为:
1.CheckPoint
2.Lazy Writer
任何在缓冲区被修改的页都会被标记为“脏”页。将这个脏页写入到数据磁盘就是CheckPoint或者Lazy
Writer的工作.
当事务遇到Commit时，仅仅是将缓冲区的所有日志页写入磁盘中的日志文件:
而直到Lazy
Writer或CheckPoint时，才真正将缓冲区的数据页写入磁盘文件:
前面说过，日志文件中的LSN号是可以比较的，如果LSN2&LSN1,则说明LSN2的发生时间晚于LSN1的发生时间。CheckPoint或Lazy
Writer通过将日志文件末尾的LSN号和缓冲区中数据文件的LSN进行对比，只有缓冲区内LSN号小于日志文件末尾的LSN号的数据才会被写入到磁盘中的数据库。因此确保了WAL（在数据写入到数据库之前，先写入日志)。
Lazy Writer和CheckPoint的区别
Lazy Writer和CheckPoint往往容易混淆。因为Lazy
Writer和CheckPoint都是将缓冲区内的“脏”页写入到磁盘文件当中。但这也仅仅是他们唯一的相同点了。
Writer存在的目的是对缓冲区进行管理。当缓冲区达到某一临界值时，Lazy
Writer会将缓冲区内的脏页存入磁盘文件中，而将未修改的页释放并回收资源。
而CheckPoint存在的意义是减少服务器的恢复时间(Recovery
Time).CheckPoint就像他的名字指示的那样，是一个存档点.CheckPoint会定期发生.来将缓冲区内的“脏”页写入磁盘。但不像Lazy
Writer,Checkpoint对SQL
Server的内存管理毫无兴趣。所以CheckPoint也就意味着在这个点之前的所有修改都已经保存到了磁盘.这里要注意的是：CheckPoint会将所有缓冲区的脏页写入磁盘，不管脏页中的数据是否已经Commit。这意味着有可能已经写入磁盘的“脏页”会在之后回滚（RollBack).不过不用担心，如果数据回滚，SQL
Server会将缓冲区内的页再次修改，并写入磁盘。
通过CheckPoint的运作机制可以看出，CheckPoint的间歇(Recovery
Interval)长短有可能会对性能产生影响。这个CheckPoint的间歇是一个服务器级别的参数。可以通过sp_config进行配置，也可以在SSMS中进行配置:
恢复间歇的默认参数是0，意味着由SQL
Server来管理这个回复间隔。而自己设置恢复间隔也是需要根据具体情况来进行界定。更短的恢复间歇意味这更短的恢复时间和更多的磁盘IO，而更长的恢复间歇则带来更少的磁盘IO占用和更长的恢复时间.
除了自动CheckPoint之外，CheckPoint还会发生在Alter DataBase以及关闭SQL
Server服务器时。sysadmin和db_backupoperator组的成员以及db_owner也可以使用CheckPoint指令来手动保存CheckPoint:
通过指定CheckPoint后的参数，SQL
Server会按照这个时间来完成CheckPoint过程，如果时间指定的短，则SQL
Server会使用更多的资源优先完成CheckPoint过程。
通常情况下，将“脏”页写入磁盘的工作，Lazy
Writer要做的比CheckPoint会多出许多。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。在 Windows 和 UNIX 上配置和优化 WebSphere MQ 性能
引言使用缺省属性创建的 IBM® WebSphere® MQ 队列管理器配置为使用适当的内存和磁盘空间来提供全功能队列管理器。不过，其中并没有针对性能进行优化，您可以进行一系列配置更改，以提高 WebSphere MQ 的消息处理性能。本文将说明如何对 Windows®、UNIX® 或 Linux® 上运行的 WebSphere MQ 队列管理器进行这些优化工作。优化选项包括：队列管理器日志队列管理器通道队列管理器侦听器队列缓冲区大小下表显示了哪个优化区域适用于哪种消息类型：应用于非持久消息应用于持久消息队列管理器日志NY队列管理器通道YY队列管理器侦听器YY队列缓冲区大小YY队列管理器的一些优化更改必须在定义队列管理器之前 实现，因此请在进行任何设置工作之前通读本文，否则可能就需要进行一些重复工作了。此类更改在相关部分中标识。建议：将优化应用到所连接的所有队列管理器，因为使用多个队列管理器的消息传递性能将依赖于所有这些队列管理器的性能。您应该有一定 Windows 和 UNIX 上的 WebSphere MQ 配置经验。本文中，参数及其值的描述基于 WebSphere MQ V6，使用了名为 MyQueueManager 的队列管理器。请在注册表项名称和目录名称中使用您的队列管理器进行相应的替换。在 UNIX 和 Linux 上配置 WebSphere MQ 时，要使用相同的设置 qm.ini 配置文件的方法。UNIX 上所有对配置参数的引用也适用于 Linux，不过本文将仅仅讨论在 UNIX 上的情况。队列管理器日志队列管理器日志配置和性能仅仅在队列管理器中处理持久消息时才需要加以注意。如果您仅使用非持久消息，则可以跳过此部分内容。这里重要的性能因素包括：日志文件位置日志写入级别日志记录类型日志文件大小日志文件扩展的数量日志缓冲区大小并发应用程序的数量工作单元内的应用程序处理其中，如果您希望更改缺省值，则必须 在创建队列管理器前作为 crtmqm 命令的选项指定日志文件位置、日志记录类型和日志文件大小。创建队列管理器后就不能更改这些队列管理器，因此将需要删除并重新定义队列管理器，以进行更改。对于其他项，您可以在创建队列管理器后通过在 Windows 注册表或 qm.ini 配置文件中的队列管理器 Log 节指定新值来进行更改。并发应用程序数量和工作单元内处理的应用程序并不算是真正的 WebSphere MQ 配置问题，而是依赖于访问队列管理器中的消息的应用程序。这些应用程序的行为可能会对队列管理器造成显著的影响，特别在出现错误时更是如此。日志文件位置概述建议：将队列管理器的日志放在独立的磁盘上，特别是在希望处理大型消息或大量消息（& 50 条消息/秒）时更应如此。在可能的情况下，将日志分配到带有电池后备写入缓存的设备上。此类设备目前在存储区域网络（Storage Area Network，SAN）中非常普遍。如果这样不现实，请使用最快的本地磁盘——例如，使用 10,000 RPM 磁盘比使用 6,000 RPM 磁盘更好。队列文件所在的设备的速度对性能并不非常重要。队列管理器对队列使用惰性写入，而对日志进行同步写入，因此如果您只要有高性能磁盘，则将其分配给日志即可。Windows 上的日志文件设置与 UNIX 上有所不同。不过，您指定位置的方式在这两个环境中都是一样的——使用 crtmqm 命令的 –ld 选项。如果要将特定的磁盘分配给队列文件和日志数据文件，则必须在定义队列管理器之前定义这些参数。Windows 上的设置使用 Windows 工具在可用的最佳设备上创建目录。例如，为日志创建名为 D:\MQM_LOG\ 的目录。如果您在一个操作系统映像上有多个队列管理器，请为每个日志使用不同的磁盘。在创建队列管理器时使用 crtmqm 命令中的 –ld 标志指定目录。以下是 crtmqm 命令的格式：crtmqm [-z] [-q] [-c Text] [-d DefXmitQ] [-h MaxHandles]
[-g ApplicationGroup]
[-t TrigInt] [-u DeadQ] [-x MaxUMsgs] [-lp LogPri] [-ls LogSec]
[-lc | -ll] [-lf LogFileSize] [-ld LogPath] QMgrNameUNIX 上的设置在 UNIX 上，您需要分配文件系统来承载队列管理器文件和日志。建议：在不同的磁盘为队列管理器和日志文件创建不同的文件系统。使用操作系统的工具分配文件系统。将日志的文件系统分配到可用的最佳设备上。以下是 UNIX (AIX) 上的此过程的示例：Filesystem
512-blocks
Free %Used
Iused %Iused Mounted on
/dev/hd9var
/dev/hd10opt
/dev/mqmlv
1% /var/mqm
/dev/mqmloglv
1% /var/mqm/log
/dev/mqmerrlv
1% /var/mqm/errors
/dev/db2lv
1% /db2data
/dev/db2loglv
1% /db2logmqmlv 逻辑卷上分配的文件系统作为 /var/mqm 加载，与使用 /var 为 WebSphere MQ 指定的文件系统不一样。类似地，mqmloglv 逻辑文件系统上分配的文件系统作为 /var/mqm/log 加载。这样分配此文件系统，可使其驻留在独立的物理磁盘上。如果在定义队列管理器时未将文件系统 /dev/mqmloglv 作为 /var/mqm/log 文件加载，日志将被分配在 /var/mqm 文件系统中，而这不是您所希望的结果。请确保在运行 crtmqm 命令创建队列管理器前分配并加载文件系统。另外，请注意已经对安装在同一台计算机上的数据库使用了相同的数据和日志分配方法，分别使用的是 /db2data 和 /db2log 装入点。日志写入级别概述您可以指定队列管理器日志程序用于可靠地写入日志记录的方法。所使用的方法在队列管理器配置的 Log 节使用 LogWriteIntegrity 参数指定。可能的值有：SingleWrite有些硬件保证，如果写入操作写入页而因为任何原因失败，对缓冲区中同一页的后续读操作将会导致缓冲区中的每个字节为以下情况之一： 和写入前一样，或者应该在写入操作中写入的字节在这种类型的硬件上（如启用了写入缓存的 SAN 磁盘），日志程序完全可以在单次写入中写入日志记录，因为硬件会保证完全的写入完整性。此方法可提供最佳的性能。DoubleWriteWebSphere MQ V5.2 中使用的缺省方法，只用于向后兼容性目的。TripleWrite缺省方法。当硬件不确保写入完整性时，应该使用 TripleWrite 方法写入日志记录，因为此方法提供完全的写入完整性。消息量大的系统（& 1000 条消息/秒）使用 SingleWrite 和 TripleWrite 的区别不大，因为只有每个日志写入操作中的最后 4k 的数据块可能会写入三次。如果您与磁盘提供商的讨论结果满意，日志所在的设备能够确保写入完整性，则请使用 SingleWrite 来获得最佳的性能。如果您更改了这个值，则必须重新启动队列管理器，以使更改生效。在 Windows 上进行更改要更改为队列管理器使用的日志写入级别，必须在注册表中更改缺省值：停止队列管理器和任何关联的应用程序。备份 Windows 注册表。运行 regedit。导航到队列管理器日志注册表项。例如：HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\MyQueueManager。选择 Log 项。双击 LogWriteIntegrity 字符串值，并根据需要修改此值。退出 regedit。重新启动队列管理器。下面的图 1 显示了队列管理器 MyQueueManager 的 Log 键值：
图 1. Log 注册表项在 UNIX 上进行更改要更改为队列管理器使用的日志写入级别，必须在队列管理器 qm.ini 文件中更改缺省值： 停止队列管理器和任何关联的应用程序。备份文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。编辑文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。如果存在 Log 节则对其进行编辑，如果不存在则创建此节。将 LogWriteIntegrity 项修改为所需的值。保存该文件。重新启动队列管理器。
以下是在 AIX 上运行的队列管理器 MyQueueManager 的 Log 项值。实际上，qm.ini 文件中可能会有其他节：#*******************************************************************#
#* Module Name: qm.ini
: WebSphere MQ queue manager configuration file
: Define the configuration of a single queue manager *#
#*******************************************************************#
#* 1) This file defines the configuration of the queue manager
#*******************************************************************#
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
LogPrimaryFiles=10
LogSecondaryFiles=10
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogPath=/var/mqm/log/MyQueueManager/
LogWriteIntegrity=SingleWrite日志记录类型概述WebSphere MQ 提供两种日志记录类型，分别为循环方式和线性方式。使用循环日志记录时，当日志文件扩展不再包括活动数据日志时，会将其进行重新使用。另一方面，使用线性日志记录时，将根据需要继续分配日志文件扩展。日志不再使用时，就可以对其进行存档。如果您需要在出现故障时转发恢复队列数据，或者从包含日志的设备的媒体故障进行恢复，而且依赖于 WebSphere MQ 来提供这种级别的保护，则必须使用线性日志记录。此方法的一个替代策略是使用磁盘镜像来对日志设备进行镜像。这通常是 SAN 提供的功能。在这种情况下，您可以使用循环日志记录。出于性能的考虑，请选择循环日志记录。循环日志记录是创建队列管理器时的缺省选项。 指定日志类型时，Windows 和 UNIX 环境的注意事项都是一样的。crtmqm 命令的 –lc 选项用于指定线性日志记录。使用 –ll 选项指定线性日志记录。尽管日志记录类型可以在队列管理器的 qm.ini 文件中指定，但在其中的任何更改都不会导致行为的变化，因为队列管理器创建之后就不能更改日志记录类型了。日志文件扩展大小概述每个日志文件扩展的大小在队列管理器创建时指定，以后不能更改，因此务必在首次定义队列管理器时就正确设置此参数。
在 Windows 和 UNIX 上指定日志文件大小的方式是一样的。即使用 crtmqm 命令的 –lf 参数指定。不过这两个平台类型的缺省值有一些区别。在 WebSphere MQ for Windows 中，缺省日志文件页数为 256，日志文件大小为 1 MB。最小日志文件页数为 32，最大为 65535。在 WebSphere MQ for UNIX 系统中，缺省日志文件页数为 1024，日志文件大小为 4 MB。最小日志文件页数为 64，最大为 65535。只要拥有足够的磁盘空间，我们都建议分配最大的大小值。日志文件扩展的数量概述日志文件扩展可以指定为主扩展或次扩展。主扩展在首次启动队列管理器时由队列管理器分配和格式化，而其他扩展是以后添加的。主扩展格式化之后就可以重新使用。次日志文件扩展由队列管理器在主文件耗尽的情况下动态分配。由于此类扩展是动态格式化的，因此在不需要的情况下，不建议使用。不过，如果活动中出现了非预期的峰值而导致主扩展被用完（例如，由于出现了长时间运行的工作单元），这就极为有用了。如果主扩展被填满，而没有更多的次扩展可用，队列管理器将选择退出尚未提交的工作单元。此行为可确保有合理数量的次扩展。日志扩展的数量可以在 crtmqm 命令上使用 –lp 标志（主扩展）和 –ls 标志（次扩展）指定，还可以在队列管理器的 Log 节使用 LogPrimaryFiles 和 LogSecondaryFiles 值指定。对于 Windows，队列管理器的 Log 节项位于 Windows 注册表中。在 UNIX 上，Log 节位于队列管理器的 qm.ini 配置文件中。
可配置的最小主日志文件个数为 2，其最大数目在 Windows 上为 254，而在 UNIX 系统上为 510 个。缺省为 3。
Windows 上主日志文件和次日志文件的总数不能超过 255，而 UNIX 系统上不超过 511，最少不能少于 3 个。操作系统限制可能会减少日志的最大可能大小。所需的扩展数量取决于要记录的数据量和每个扩展的大小。实际的起点可以为 LogPrimaryFiles=10 和 LogSecondaryFiles=10。在 Windows 上进行更改如果您希望更改为队列管理器分配的日志文件扩展的数量，您将需要在注册表中更改这些值：停止队列管理器和任何关联的应用程序。备份 Windows 注册表。运行 regedit。导航到队列管理器日志注册表项。例如，HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\MyQueueManager。选择 Log 项。双击 LogPrimaryFiles 字符串值，并根据需要修改此值，以更改主扩展的数量。如果希望更改次扩展的数量，请对注册表项 LogSecondaryFiles 进行类似的修改。退出 regedit。重新启动队列管理器。有关 Log 项中的 LogPrimaryFiles 和 LogSecondaryFiles 参数的视图，请参见。在 UNIX 上进行更改如果您希望更改为队列管理器分配的日志文件扩展的数量，您将需要在 qm.ini 文件中更改缺省值：停止队列管理器和任何关联的应用程序。备份文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。编辑文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。如果存在 Log 节则对其进行编辑，如果不存在则创建此节。将 LogPrimaryFiles 条目修改为所需的值，以更改主扩展的数量。如果希望更改次扩展的数量，请对 LogSecondaryFiles 条目进行类似的修改。保存该文件。重新启动队列管理器。有关 LogPrimaryFiles 和 LogSecondaryFiles 参数在 qm.ini 文件的 Log 节中的视图，请参见上面中的“在 UNIX 上进行更改”。日志缓冲区大小概述日志缓冲区是用于存放将要写入磁盘中的日志记录的主存量。日志记录追加到日志缓冲区中已使用的部分的尾部。达到缓冲区尾部后，需要进行某种序列化操作，以降低数据传输到磁盘的速率。大型缓冲区不会像较小的缓冲区那样经常达到这个极限。 根据队列管理器所在的平台，您可以使用队列管理器的 Log 节的 LogBufferPages 参数以 4KB 页为单位指定缓冲区大小。缓冲区页面最少为 18，最大为 4097。较大的缓冲区能提供更高的吞吐量，尤其能很好地处理较大的消息。如果您指定 0（缺省值），队列管理器将选择大小。在 WebSphere MQ Version 6.0 中，此值为 128 (512 KB)。如果指定的是 1 到 17 之间的数，队列管理器将缺省使用 18 (72 KB)。如果指定的值在 18 到 4096 之间，队列管理器将使用指定的数字设置所分配的内存。此值在 Windows 上使用注册表指定，而在 UNIX 上使用 qm.ini 文件指定。可以在定义队列管理器之后更改此值。不过，在队列管理器重新启动之前，此值的更改将不会生效。为了提高性能，请指定最大的可能值。这将有助于写入大量日志数据的情况，允许在单次日志 I/O 中写入大型消息。这样的设置将会使存储使用率有一定的增加。使用大值将不会在写入少量数据时影响性能，但如果写入大量数据时指定了小值，就可能导致队列管理器必须发出多次写入日志的命令，从而影响性能。在 Windows 上进行更改如果您希望更改队列管理器的日志缓冲区大小，将需要在注册表中更改此值：停止队列管理器和任何关联的应用程序。备份 Windows 注册表。运行 regedit。导航到队列管理器日志注册表项。例如，HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\MyQueueManager。选择 Log 项。双击 LogBufferPages 项，并根据需要修改此值，以更改分配的页数量。退出 regedit。重新启动队列管理器。下面的图 2 显示了将 LogBufferPages 更改为 4096 后的 Log 注册表项。
图 2. 更改了 LogBufferPages 的缺省值后的 Log 注册表项在 UNIX 上进行更改如果您希望更改队列管理器的日志缓冲区大小，将需要在队列管理器 qm.ini 文件中更改此值：停止队列管理器和任何关联的应用程序。备份文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。编辑文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。如果存在 Log 节则对其进行编辑，如果不存在则创建此节。将 LogBufferPages 条目修改为所需的值，以指定要分配的页数量。保存该文件。重新启动队列管理器。
以下是将 LogBufferPages 值更改为 4096 后 Log 节的内容。在实际中，qm.ini 文件中可能还包括其他节的内容。#*******************************************************************#
#* Module Name: qm.ini
: WebSphere MQ queue manager configuration file
: Define the configuration of a single queue manager *#
#*******************************************************************#
#* 1) This file defines the configuration of the queue manager
#*******************************************************************#
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
LogPrimaryFiles=10
LogSecondaryFiles=10
LogFilePages=4096
LogType=CIRCULAR
LogBufferPages=4096
LogPath=/var/mqm/log/MyQueueManager/
LogWriteIntegrity=SingleWrite并发应用程序的数量处理持久消息时，建议并行运行应用程序的多个实例，以优化队列管理器日志的效率。完全可能让数十或数百个应用程序并发执行，而不会对队列管理器日志性能造成任何负面影响。在这种情况下，提交时日志写入的开销会分散到多个应用程序。应用程序处理和工作单元处理应用程序中的持久消息时，应确保所有 MQPUT 和 MQGET 活动在一个工作单元（有时候也称为同步点）中进行，以提高效率。持久消息的每个 MQPUT、MQGET、MQCMIT 都会导致创建日志记录，以便以后进行恢复。这些记录必须成功写入到队列管理器日志，以便应用程序能够正确地提交其更新。写入的时间和频率将根据消息是否在工作单元中处理而有所差异。当应用程序在一个工作单元中发出所有 MQPUT 和 MGET 操作时，队列管理器能够允许多个应用程序并发地处理相同队列上的不同消息。当这些应用程序发出提交命令 (MQCMIT) 时，可以在队列上使用共享锁定。这就意味着多个应用程序能够同时提交更新。这对消息吞吐量而言非常好。在这种情况下，在工作单元期间创建的所有日志记录都必须成功地写入到日志中，以便提交能成功完成。这就要求日志记录对每个应用程序的每个工作单元仅进行一次。在工作单元或同步点外处理持久消息的应用程序必须在每个 MQGET 或 MQPUT 之后等待日志记录同步写入到日志中。这就可能需要每次应用程序调用进行多次日志写入操作。由于当使用具有 5-10 毫秒 SCSI 磁盘写入缓存时间的磁盘时，各个 I/O 时间相差可达半毫秒之多，因此这可能对总体性能造成极大的影响。此外，在进行日志写入时，队列无法供其他应用程序使用。这就会影响整个处理，对消息吞吐量而言很不好。从性能角度来说，正是由于这个原因，才务必让所有的应用程序在工作单元内处理持久消息。只要有一个应用程序没有遵循此规则，就会对持久消息处理造成负面影响。不过，实际上，可能会在某些情况下希望在工作单元外写入消息，因此需要确保无论工作单元成功与否都将进行写入。这种方式有时候用于跟踪特定活动的审核目的。在这种情况下，功能需求可能优先于性能考虑。队列管理器通道WebSphere MQ 队列管理器用于与其他队列管理器相互接收和发送消息的通道可以作为受信任或 Fastpath MQ 应用程序运行。
将 MQ 应用程序作为受信任对象运行的好处在于，这样可通过缩短的代码路径长度提供性能优势。Fastpath 应用程序在与队列管理器相同的进程中运行，因此能够更高效地与队列管理器通信。这意味着 Fastpath 应用程序和队列管理器之间不存在进程分离。相反，当作为非 Fastpath 或标准应用程序运行时，名为 amqzlaa 的代理进程将提供 MQ 应用程序和队列管理器之间的分离。在这种情况下，应用程序和队列管理器之间的分离状况更好，但在性能方面会有所损失。由于通道是 WebSphere MQ 产品代码，而且非常稳定，因此完全可以将通道作为受信任应用程序运行。
有几个注意事项需要记住：如果使用了通道出口，您可能要重新考虑将通道作为受信任应用程序运行的做法，因为如果出口编写不正确而且没有经过全面的测试，出口可能会破坏队列管理器。如果使用 STOP CHANNEL(TERMINATE) 命令，也应该重新考虑是否将通道作为受信任应用程序运行。如果您的环境不稳定，经常出现组件故障，也可能要重新考虑是否将通道作为受信任应用程序运行。有两个选项可用于将通道作为受信任应用程序运行。 在 qm.ini 或注册表文件中的 Channels 节指定值 MQIBindType=FASTPATH。此值区分大小写。如果指定的值无效，将会被忽略。有关如何在 Winows 和 UNIX 环境中进行此操作，请参见下文。通过选择此选项，队列管理器中的所有通道都将作为受信任应用程序运行。在启动通道的环境中将环境变量 MQ_CONNECT_TYPE 设置为 FASTPATH 值。确保设置 MQ_CONNECT_TYPE=FASTPATH 作为环境变量显示。此值区分大小写。如果指定的值无效，将会被忽略。 建议仅使用其中一个选项。在 Windows 上进行更改如果您希望将通道作为 Fastpath 或队列管理器的受信任应用程序运行，则将需要向注册表添加一个参数：停止队列管理器和任何关联的应用程序。备份 Windows 注册表。运行 regedit。导航到队列管理器日志注册表项。例如，HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\MyQueueManager。如果不存在 Channel 注册表项，则创建此项。在 Channel 注册表项内创建名为 MQIBindType 的字符串值。将 MQIBindType 的值设置为 FASTPATH。退出 regedit。重新启动队列管理器。下面的图 3 显示了在 Windows 上运行的队列管理器的 Channel 注册表项，其中已经添加了 MQIBindType 值。
图 3. 添加了 Channel 注册表项和 MQIBindType 值后的注册表的屏幕截图
在 UNIX 上进行更改如果您希望将通道作为 Fastpath 或队列管理器的受信任应用程序运行，将需要在队列管理器 qm.ini 文件中更改此值。停止队列管理器和任何关联的应用程序。备份文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。编辑文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。如果不存在 Channel 节，则添加此节。在 Channel 节内添加 MQIBindType 值，并为其指定 FASTPATH 值。保存该文件。重新启动队列管理器。
以下是添加了 MQIBindType 值后的 Channels 节的内容。在实际中，qm.ini 文件中可能会有其他节。#*******************************************************************#
#* Module Name: qm.ini
: WebSphere MQ queue manager configuration file
: Define the configuration of a single queue manager *#
#*******************************************************************#
#* 1) This file defines the configuration of the queue manager
#*******************************************************************#
MQIBindType=FASTPATH队列管理器侦听器就像通道可以作为受信任应用程序运行一样，也可以将侦听器作为受信任应用程序运行。为此，在启动侦听器的环境中将环境变量 MQ_CONNECT_TYPE 设置为 FASTPATH 值。这样可确保 MQ_CONNECT_TYPE=FASTPATH 作为环境变量显示。此值区分大小写。如果指定的值无效，将会被忽略。此方法适用于以下情况的侦听器：手动或在脚本中运行 runmqlsr 命令时已启动。已经在 runmqsc 中使用 Define listener 命令定义。对于选项 1，MQ_CONNECT_TYPE=FASTPATH 只需要出现在从其中发出 runmqlsr 命令的 shell 中。并不需要出现在队列管理器的其他部分。对于选项 2，必须在启动队列管理器的环境中设置 MQ_CONNECT_TYPE=FASTPATH。这通常可以通过在队列管理器运行所使用的用户 ID 的 .profile 文件中设置环境变量来实现。这对于 Windows 和 UNIX 环境都一样。代理进程如果您已经决定全部使用受信任应用程序，可以通过一项有用的检查确保没有代理进程，即运行命令 ps -ef |grep amqzlaa。
应该不出现代理进程。很难确定哪些 MQ 应用程序与某个特定代理关联。如果您需要删除代理，将必须通过消除进程的方式进行此工作。另外，可以使用一个非常有用的命令查看进程 环境变量，即命令 ps eww。此命令可提供进程编号作为额外参数运行。比如可以运行 ps eww 106896。例如，在要确定是否针对 MQ 侦听器设置了 MQ_CONNECT_TYPE，就可以使用此命令。队列缓冲区大小队列管理器中的每个队列都分配了两个缓冲区来承载消息，一个用于非持久消息，另一个用于持久消息。消息从缓冲区溢出后，将移动到操作系统文件系统。可以更改缓冲区大小来限制这种上溢，从而提高数据对队列管理器的可用性。32 位的队列管理器（Windows、Linux32）的非持久消息缓冲区缺省大小为 64k，而 64 位队列管理器（AIX、Solaris、HPUX、Linux64）的非持久消息缓冲区缺省大小为 128K。32 位队列管理器的持久消息缓冲区缺省大小为 128K，而 64 位队列管理器的持久消息缓冲区缺省大小为 256K。两种队列缓冲区支持的最大的大小都是 100MB。更改缓冲区大小将会增加队列管理器的存储需求。存储方面的增长将依赖于缓冲区的大小和其应用到的队列的数量。使用大型非持久或持久队列缓冲区定义队列时，如果系统由于已经定义了具有大型缓冲区的大量队列或其他原因（例如，定义了大量通道）导致实际内存短缺，则可能会导致性能下降。在增加这些值时请谨慎行事。您应该确定增大大小会对消息吞吐量带来好的影响。如果不是这样，则不应继续增大缓冲区的大小。选择值时，您需要确定队列上的平均消息大小以及队列上的平均消息数量。因为 WebSphere MQ 中所有基于队列的处理都是以低队列深度为目标。非持久队列缓冲区使用名称为 DefaultQBufferSize 的优化参数指定。持久队列缓冲区使用名称为 DefaultPQBufferSize 的优化参数指定。可以使用不同的 DefaultQBufferSize 和 DefaultPQBufferSize 值定义队列。不过，任何时候都只能在队列管理器中为 DefaultQBufferSize 和 DefaultPQBufferSize 分别指定一个值。队列使用的值是在定义队列时生效的值。而这又取决于当时在队列管理器中生效的值。队列管理器中的值由队列管理器最后一次启动时 TuningParameters 节中出现的值决定。当队列管理器使用新值重新启动时，现有队列将保持其之前的定义，而新队列将使用当前参数值创建。当打开队列时，将根据创建队列时在磁盘上保存的定义分配队列资源。队列的缓冲区大小将保留到队列管理器重启之前。要更改缓冲区大小，请执行以下操作：删除希望更改的任何现有队列。停止队列管理器。在 Windows 注册表或 qm.ini 文件中添加或更改 TuningParameters 节的内容。重新启动队列管理器。定义队列。如果您希望不同的队列具有不同的 DefaultQBufferSize 设置，则需要重复步骤 2、3、4、5，并在步骤 3 中更改缓冲区大小，然后在步骤 5 中仅定义需要这个特定值的队列。然后在步骤 3 的下一个迭代中重复下一个缓冲区大小。Windows 和 UNIX 上增加缓冲区大小的过程有所不同。下面将对两种情况进行说明。您应该注意的是，队列管理器没有关于错误语法的反馈。在 Windows 上进行更改删除希望更改的对象。停止队列管理器和任何关联的应用程序。运行 regedit。导航到队列管理器日志注册表项。例如 HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\MyQueueManager。如果不存在注册表项 TuningParameters，则创建此项。导航到 TuningParameters 项。要更改非持久缓冲区大小，请在 TuningParameters 项中创建名为 DefaultQBufferSize 的字符串，并以字节方式指定其值。例如，值 1048576 指定缓冲区大小为 1 MB。最大值为 100MB。要更改持久缓冲区大小，请在 TuningParameters 项中创建名为 DefaultPQBufferSize 的字符串，并以字节方式指定其值。例如，值 1048576 指定缓冲区大小为 1MB。最大值为 100MB。退出 regedit。重新启动队列管理器。定义应用程序队列。
下面的图 4 显示了将 DefaultPQBufferSize 和 DefaultQBufferSize 设置为 1MB 的 TuningParameters 注册表项。图 4. Windows 队列管理器的 TuningParameters 节屏幕截图在 UNIX 上进行更改删除希望更改的对象。停止队列管理器和任何关联的应用程序。备份文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。编辑文件 /var/mqm/qmgrs/MyQueueManager/qm.ini。如果没有名为 TuningParameters 的节，则添加此节。要更改非持久缓冲区大小，请在 TuningParameters 节中创建名为 DefaultQBufferSize 的条目，并以字节方式指定其值。例如，值 1048576 指定缓冲区大小为 1 MB。最大值为 100MB。要更改持久缓冲区大小，请在 TuningParameters 节中创建名为 DefaultPQBufferSize 的条目，并以字节方式指定其值。例如，值 1048576 指定缓冲区大小为 1MB。最大值为 100MB。保存该文件。重新启动队列管理器。定义队列。
以下是将 DefaultPQBufferSize 和 DefaultQBufferSize 设置为 1MB 的 TuningParameters 节的内容。在实际中，qm.ini 文件中可能会有其他节。#*******************************************************************#
#* Module Name: qm.ini
: WebSphere MQ queue manager configuration file
: Define the configuration of a single queue manager *#
#*******************************************************************#
#* 1) This file defines the configuration of the queue manager
#*******************************************************************#
TuningParameters:
DefaultQBufferSize=1048576
DefaultPQBufferSize=1048576只要 DefaultQBufferSize 和 DefaultPQBufferSize 在 TuningParameters 中，而且队列管理器已经重新启动来读取这些值，这些值就将应用到随后定义的所有队列。如果您希望仅将这些值应用到某组特定的队列，则应该只在这些值生效时定义这些队列。在定义任何其他采用不同值的队列前，请删除或更改设置并重新启动队列管理器。有关更改队列缓冲区大小的更多信息，请参见 SupportPac MP01:MQSeries – Tuning Queue Limits in Version 5 Products。 快速入门在此部分，我们将提供一个指南，帮助您快速配置具有用于处理持久和非持久消息的优化设置的队列管理器。这对于开发或测试队列管理器非常有用。在规划生产环境时，您应该花时间正式地对所需的日志空间进规划（请参见 MQ 文档），因为您不希望在生产环境中出现日志空间耗尽的情况。以下是相关步骤：分配独立的文件系统或目录，以使日志位于独立的磁盘上。对于 UNIX，文件系统应该名为 /var/mqm/log。确保在创建队列管理器前加载 /var/mqm/log。使用命令
crtmqm -lp 10 -ls 10 -lf 65535 &queue manager_name&
创建队列管理器。这意味着：
队列管理器日志文件大小为 65535（通过 -lf 65535 选项）。使用循环日志记录。这是缺省设置，因此不需要指定。使用 -lp 10 和 -ls 10 标志为日志指定 10 个主扩展和 10 个次扩展。在 UNIX 上保存 /var/mqm/qmgrs/&queue manager_name&/qm.ini，或在 Windows 上备份注册表。在 UNIX 上编辑 /var/mqm/qmgrs/&queue manager_name&/qm.ini，或在 Windows 上使用 regedit 并导航到 HKEY_LOCAL_MACHINE\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\&queue manager_name&。将 Log 节或注册表项中的 LogBufferPages 的值更改为 4096。创建（或修改） Channels 节或注册表项，并添加以下条目，注意大小写
MQIBindType=FASTPATH创建（或修改）TuningParameters 节或注册表项，并将以下条目作为值添加，注意大小写
DefaultQBufferSize=1048576
DefaultPQBufferSize=1048576保存 qm.ini 或退出 regedit。确保发出 runmqlsr 命令的 shell 或命令提示符中将 MQ_CONNECT_TYPE=FASTPATH 设置为了环境变量。 启动队列管理器。定义应用程序队列。在本例中，队列缓冲区大小设置为了 1MB (48576)。可以根据需要使用不同的值。为何缺省队列管理器不是最优设置为了说明队列管理器的缺省值与我们在优化队列管理器时通常设置的值的差异情况，这一部分我们将了解在 UNIX 上为队列管理器设置的缺省值。以下是 UNIX 上缺省队列管理器的 qm.ini 文件。此队列管理器使用命令 crtmqm MyQueueManager 创建。这就意味着所有的参数值都是缺省设置的。#*******************************************************************#
#* Module Name: qm.ini
: WebSphere MQ queue manager configuration file
: Define the configuration of a single queue manager *#
#*******************************************************************#
#* 1) This file defines the configuration of the queue manager
#*******************************************************************#
ExitsDefaultPath=/var/mqm/exits/
ExitsDefaultPath64=/var/mqm/exits64/
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=1024
LogType=CIRCULAR
LogBufferPages=0
LogPath=/var/mqm/log/MyQueueManager/
LogWriteIntegrity=TripleWrite
Name=AuthorizationService
EntryPoints=13
serviceComponent:
Service=AuthorizationService
Name=MQSeries.UNIX.auth.service
Module=/usr/mqm/lib64/amqzfu
ComponentDataSize=0虽然此配置将指定一个能够非常正常地处理非持久消息和持久消息的队列管理器，但性能并没有得到优化。 :LogPrimaryFiles 仅设置为 3。我们通常会希望使用更高的值。LogSecondaryFiles 仅设置为 2。我们通常会希望使用更高的值。LogType 设置为循环。如果我们不希望使用线性日志记录，这个设置合适。LogBufferPages 设置为 0（实际为 128）。如果我们希望处理高消息速率或处理大型持久消息，这个值就小了。LogWriteIntegrity 设置为 TripleWrite。在理想情况，我们会希望将日志放在可靠的设备上，然后会使用 SingleWrite 值。其中没有通道对应的节。因此，除非建立环境变量 MQ_CONNECT_TYPE=FASTPATH，否则通道将作为标准应用程序运行。其中没有 TuningParameters 节，不能更改缺省队列缓冲区大小的值。因此所有队列的缺省非持久消息缓冲区大小都为 64K（32 位操作系统）/128K（64 位操作系统），缺省持久消息缓冲区大小都为 128K（32 位操作系统）/256K（64 位操作系统）。根据所处理的消息的大小不同，此设置可能够用，也可能不够用。在 Windows 系统上分配的缺省队列管理器也会有同样的考虑。虽然都是两种操作系统类型上的缺省值，但有些特定参数的值可能会有所不同。
相关主题您可以参阅本文在 developerWorks 全球站点上的
。您可能会对以下 SupportPacs 感兴趣：
以下 SupportPacs 文档结果均是通过使用优化设置得到的：
帮助您使用 WebSphere MQ 设计、开发和部署消息传递中间件的技术资源，以在几乎所有平台上对应用程序、Web 服务和事务进行集成。产品说明、产品新闻、培训信息和支持信息等等。免费下载 WebSphere MQ V6 试用版。包括在试用期间提供 Windows® 和 Linux® 安装的免费有限在线支持。所有 WebSphere MQ V6 文档的基于 Eclipse 的统一 Web 门户，提供了有关安装、配置和使用 WebSphere MQ 环境的概念、任务和参考信息。WebSphere MQ 产品手册。针对 WebSphere MQ 系列产品的可下载代码、文档和性能报告。一个非 IBM 论坛，您可以从中获得 WebSphere MQ 技术问题的答案，并与其他用户分享 WebSphere MQ 知识。对于开发人员，可以访问 WebSphere Business Integration 文章、行业解决方案和产品信息等等。为企业和技术用户提供方便的对所有 WebSphere Business Integration 产品的概述。 免费下载主要的 WebSphere 产品试用版。通过 Barnes & Noble 进行方便的在线订购。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=WebSphereArticleID=285073ArticleTitle=在 Windows 和 UNIX 上配置和优化 WebSphere MQ 性能publish-date=}