performance - XMITQ 上的 MQ 慢出队速率

问题描述

我们一直面临一个问题，即 xmitq 的消息速率与正常性能相比非常慢。我们有许多其他具有更大 MQ 流的 Qmgrs，它们没有同样的问题。

我们的HUB qmgr连接到同一公司HUB qmgr的业务线，即使他们这边的目的地队列是空的，流量也很慢。

在操作系统和网络级别，他们说无能为力。在 MQ，我们更改了 Buffersizes，使其与操作系统级别匹配并使用系统 tcp 窗口。

现在在 MQ 级别，我们将通道 SDR 设置为 BATCHSZ 为 100，但似乎接收器配置为 30。我们注意到这是因为我们看到消息以 30 条消息的批次流动。也不确定这是否相关，但我们看到 XMITQ 总是有 30 条未提交的消息。

我们的问题寻求建议。

增加 SDR/RCVR 上的 BATCHSZ 参数会有助于提高性能吗？MQ 级别是否有任何其他参数可以帮助它？

 DIS CHS(NAME) ALL

AMQ8417: Display Channel Status details.
 CHANNEL(QMGRA.QMGRB.T7)           CHLTYPE(SDR)
 BATCHES(234)                            BATCHSZ(30)
 BUFSRCVD(235)                           BUFSSENT(6391)
 BYTSRCVD(6996)                          BYTSSENT(14396692)
 CHSTADA(2020-04-16)                     CHSTATI(14.38.17)
 COMPHDR(NONE,NONE)                      COMPMSG(NONE,NONE)
 COMPRATE(0,0)                           COMPTIME(0,0)
 CONNAME(159.50.69.38(48702))            CURLUWID(398F3E5EEA43381C)
 CURMSGS(30)                             CURRENT
 CURSEQNO(43488865)                      EXITTIME(0,0)
 HBINT(300)                              INDOUBT(YES)
 JOBNAME(000051FC00000001)               LOCLADDR(10.185.8.122(54908))
 LONGRTS(999999999)                      LSTLUWID(398F3E5EE943381C)
 LSTMSGDA(2020-04-16)                    LSTMSGTI(14.49.46)
 LSTSEQNO(43488835)                      MCASTAT(RUNNING)
 MONCHL(HIGH)                            MSGS(6386)
 NETTIME(2789746,3087573)                NPMSPEED(NORMAL)
 RQMNAME(QMGRB)                       SHORTRTS(10)
 SSLCERTI(*******************)
 SSLKEYDA( )                             SSLKEYTI( )
 SSLPEER(*******************)
 SSLRKEYS(0)                             STATUS(RUNNING)
 STOPREQ(NO)                             SUBSTATE(RECEIVE)
 XBATCHSZ(23,7)                          XMITQ(QMGRB.X7)
 XQTIME(215757414,214033427)             RVERSION(08000008)
 RPRODUCT(MQMM)

qm.ini：

Log:
 LogPrimaryFiles=10
 LogSecondaryFiles=10
 LogFilePages=16384
 LogType=LINEAR
 LogBufferPages=4096
 LogPath=/apps/wmq/QMGR/log/QMGR/
 LogWriteIntegrity=SingleWrite
Service:
 Name=AuthorizationService
 EntryPoints=13
TCP:
 SvrSndBuffSize=0
 SvrRcvBuffSize=0 
 ServiceComponent:
 Service=AuthorizationService
 Name=MQSeries.UNIX.auth.service
 Module=/opt/mqm75/lib64/amqzfu
 ComponentDataSize=0
Channels:
 MaxChannels=500

更新时间：格林威治标准时间 15:41

只是为了更新信息，双方现在都使用 BATCHSZ 100 并且似乎略有不同。

AMQ8417: Display Channel Status details.
 CHANNEL(QMGRA.QMGRB.T7)           CHLTYPE(SDR)
 BATCHES(403)                            BATCHSZ(100)
 BUFSRCVD(405)                           BUFSSENT(23525)
 BYTSRCVD(11756)                         BYTSSENT(53751066)
 CHSTADA(2020-04-17)                     CHSTATI(15.13.51)
 COMPHDR(NONE,NONE)                      COMPMSG(NONE,NONE)
 COMPRATE(0,0)                           COMPTIME(0,0)
 CONNAME(159.50.69.38(48702))            CURLUWID(6D66985E94343410)
 CURMSGS(0)                              CURRENT
 CURSEQNO(44115897)                      EXITTIME(0,0)
 HBINT(300)                              INDOUBT(NO)
 JOBNAME(0000172A00000001)               LOCLADDR(10.185.8.122(2223))
 LONGRTS(999999999)                      LSTLUWID(6D66985E93343410)
 LSTMSGDA(2020-04-17)                    LSTMSGTI(15.30.06)
 LSTSEQNO(44115897)                      MCASTAT(RUNNING)
 MONCHL(HIGH)                            MSGS(23505)
 NETTIME(101563,480206)                  NPMSPEED(NORMAL)
 RQMNAME(QMGRB)                       SHORTRTS(10)
 SSLCERTI(*************************************)
 SSLKEYDA( )                             SSLKEYTI( )
 SSLPEER(****************************)
 SSLRKEYS(0)                             STATUS(RUNNING)
 STOPREQ(NO)                             SUBSTATE(MQGET)
 XBATCHSZ(1,1)                           XMITQ(QMGRB.X7)
 XQTIME(191225,794134)                   RVERSION(08000008)
 RPRODUCT(MQMM)

AMQ8450: Display queue status details.
 QUEUE(QMGRB.X7)                      TYPE(QUEUE)
 CURDEPTH(0)                             IPPROCS(1)
 LGETDATE(2020-04-17)                    LGETTIME(15.30.06)
 LPUTDATE(2020-04-17)                    LPUTTIME(15.30.06)
 MEDIALOG(S2488154.LOG)                  MONQ(LOW)
 MSGAGE(0)                               OPPROCS(9)
 QTIME(794134, 191225)                   UNCOM(NO)

标签： performanceibm-mq

解决方案

我将在这个答案中提出一些意见，但根据任何进一步的反馈，我可能会添加更多。

您在发送方运行一个非常旧版本的软件，MQ 7.5 几乎在两年前（2018 年 4 月 30 日）停止了支持。IBM 将提供额外三年的扩展支持，因此您可能属于该组。7.5.0.2 维护版本本身于 2013 年 7 月 11 日发布，所以此时它已经快七年了。我强烈建议您升级到更新的版本。

请注意，MQ v8.0 将于 2020 年 4 月 30 日停止支持，而 IBM 几天前刚刚宣布 MQ v9.0 将于 2021 年 9 月 30 日停止支持。当您进行迁移时，您应该选择没有宣布结束的 9.1支持（他们至少提供五年，因此可能是 2023 年），或者选择今年应该推出的下一个 MQ 版本。

您提到设置以下内容：

TCP:
 SvrSndBuffSize=0
 SvrRcvBuffSize=0

上述设置适用于SVRCONN客户端连接的结束。您可以在 MQ v7.5 知识中心页面WebSphere MQ>Configuring>Changing configuration information>Changing queue manager configuration information>TCP、LU62、NETBIOS 和 SPX中看到这一点：

SvrSndBuffSize=32768|number客户端连接服务器连接通道的服务器端
使用的 TCP/IP 发送缓冲区的大小（以字节为单位）。

SvrRcvBuffSize=32768|number客户端连接服务器连接通道的服务器端
使用的 TCP/IP 接收缓冲区的大小（以字节为单位）。

在 IBM MQ v7.5.0.2 APAR IV58073 中引入了将各种缓冲区设置设置为值 0 的概念，这意味着它将允许使用操作系统默认值。不幸的是，就像知识中心中的许多事情一样，IBM 似乎没有为 7.5 正确记录这一点。

但是，您可以查看 IBM MQ v8.0 知识中心，以在页面配置>更改配置信息>更改队列管理器配置信息>TCP、LU62 和 NETBIOS上获取有关这些设置的完整图片，特别是您希望设置这两个设置对您的发件人频道产生任何影响：

SndBuffSize=数字| 0通道发送端
使用的 TCP/IP 发送缓冲区的大小（以字节为单位）。此节值可以被更特定于通道类型的节覆盖，例如 RcvSndBuffSize。如果该值设置为零，则使用操作系统默认值。如果未设置任何值，则使用 IBM MQ 缺省值 32768。

RcvSndBuffSize=数字| 0接收通道的发送端
使用的 TCP/IP 发送缓冲区的大小（以字节为单位）。如果该值设置为零，则使用操作系统默认值。如果未设置任何值，则使用 IBM MQ 缺省值 32768。

从 IBM MQ v8.0 开始，任何新创建的队列管理器都将包含以下所有内容qm.ini：

TCP:
   SndBuffSize=0
   RcvBuffSize=0
   RcvSndBuffSize=0
   RcvRcvBuffSize=0
   ClntSndBuffSize=0
   ClntRcvBuffSize=0
   SvrSndBuffSize=0
   SvrRcvBuffSize=0

但是，默认情况下，任何升级的队列管理器都不会获得这些设置，这意味着如果这些设置不存在，它们将不会被添加，如果它们存在，它们将保持不变。如果该设置不存在，那么正如上面所说的“使用 IBM MQ 默认值 32768”。

我与 IBM 支持人员就该主题进行了广泛讨论，得出的结论是，他们没有看到任何不将其设置为 0 的理由，他们只看到了这样做的好处，但非常谨慎地他们不会将其更改为 0为你。

我建议您将所有这些添加到您的qm.ini.，但至少添加我上面突出显示的两个。

这些是很好的实施设置，但如果最近两端没有任何变化，可能无法解决您的问题。但是，如果确实发生了某些变化，例如网络差异，或者 MQ 在远程端升级到 8.0.0.8，那么此设置可能会解决您的问题。

在通道状态输出中，有两个值很有趣：

NETTIME(2789746,3087573)
XQTIME(215757414,214033427)

NETTIME 意味着根据最近的活动，从 RCVR 频道接收响应需要 2.7 秒，而在更长的时间内，从 RCVR 频道接收响应需要 3.1 秒。您能否将此与从发送通道服务器到接收通道服务器的 TCP ping 进行比较，通过网络响应的 2.7 秒似乎过多。在Capitalware 的 MQ 技术会议 v2.0.1.4 上发表的保持 MQ 通道正常运行的演讲中，曾为 IBM 工作的 Paul Clarke 表示“NETTIME 仅测量网络时间，例如不包括 MQCMIT”。

XQTIME 意味着根据最近的活动和更长的一段时间，XMITQ 上的消息被 SDR 通道接收到发送需要大约 215 秒。

请参阅下文了解 IBM 如何记录这些内容：

NETTIME
向通道的远程端发送请求并接收响应的时间量，以微秒为单位。该时间仅测量此类操作的网络时间。显示两个值：

基于短期内近期活动的值。

基于较长时期内活动的值。

XQTIME
消息在被检索之前保留在传输队列中的时间（以微秒为单位）。该时间是从将消息放入传输队列到检索到它以在通道上发送的时间，因此，包括由放入应用程序中的延迟引起的任何时间间隔。
显示两个值：

基于短期内近期活动的值。

基于较长时期内活动的值。

有关BATCHSZ通道参数的信息可以在 IBM MQ v8.0 知识中心页面参考>配置参考>通道属性>按字母顺序排列的通道属性>批量大小 (BATCHSZ)中找到。我已经引用了它并用粗体突出了一些区域。

此属性是在获取同步点之前要发送的最大消息数。

批量大小不影响通道传输消息的方式；消息始终单独传输，但作为批处理提交或回退。

为了提高性能，您可以设置批处理大小来定义要在两个同步点之间传输的最大消息数。在通道启动时协商要使用的批大小，并采用两个通道定义中的较低者。在某些实现中，批处理大小是根据两个通道定义中的最小值和两个队列管理器 MAXUMSGS 值计算的。批次的实际大小可以更小；例如，当传输队列上没有消息或批处理间隔到期时，批处理完成。

较大的批处理大小值会增加吞吐量，但会增加恢复时间，因为有更多消息要退出并再次发送。默认 BATCHSZ 为 50，建议您先尝试该值。如果您的通信不可靠，您可能会为 BATCHSZ 选择较低的值，从而更有可能需要恢复。

此属性对以下通道类型有效：

发件人

服务器

接收者

请求者

集群发送者

集群接收器

跟进问题：

PUT 到此 XMITQ 的消息是否持久？
答：是的，在我们的 PROD 环境中，所有消息都是持久的。
你最近有没有增加这个 XMITQ 的交易量？
答：不，我们使用了监控工具，我们提取了一份报告，该报告显示在此期间的消息率非常相似。过去 2 周的利率相同。
MQPMO_SYNCPOINT在将1 条或多条消息放入队列后，放置应用程序是否设置并提交？
答：我会与申请团队核实。

performance - XMITQ 上的 MQ 慢出队速率

问题描述

解决方案

推荐阅读