XMITQ 上的 MQ 出队速度慢
MQ slow dequeuing rates on a XMITQ
我们一直面临一个问题，即 xmitq 的消息速率与正常性能相比非常慢。
我们有许多其他具有更大 MQ 流的 Qmgr 没有同样的问题。
我们的HUB qmgr连接到同一个公司HUB qmgr的业务线，连他们这边的destination queue都是空的，流量真的很慢。
在 OS 和网络级别，他们说无能为力。在 MQ，我们更改了缓冲区大小，使其匹配 OS 级别并使用系统 tcp windows.
现在在 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)
我会在这个答案中提出一些意见，但根据任何进一步的反馈，我可能会添加更多内容。
你是 运行 发送方软件的一个非常旧的版本，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, and SPX:
SvrSndBuffSize=32768|number
The size in bytes of the TCP/IP send buffer used by the server end of a client-connection
server-connection channel.
SvrRcvBuffSize=32768|number
The size in bytes of the TCP/IP receive buffer used by the server end of a client-connection
server-connection channel.
在 IBM MQ v7.5.0.2 APAR IV58073 中引入了将各种缓冲区设置设置为 0 的概念，这意味着它将允许使用操作系统默认值。不幸的是，与知识中心中的许多内容一样，IBM 似乎没有为 7.5 正确记录这一点。
但是，您可以查看 IBM MQ v8.0 知识中心，以在页面 Configuring>Changing configuration information>Changing queue manager configuration information>TCP, LU62, and NETBIOS 上全面了解这些设置，特别是您希望设置这两个设置以对您的发件人产生任何影响频道：
SndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sending end of
channels. This stanza value can be overridden by a stanza more
specific to the channel type, for example RcvSndBuffSize. If the
value is set as zero, the operating system defaults are used. If no
value is set, then the IBM MQ default, 32768, is used.
RcvSndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sender end of
a receiver channel. If the value is set as zero, the operating system
defaults are used. If no value is set, then the IBM MQ default, 32768,
is used.
从 IBM MQ v8.0 开始，任何新创建的队列管理器都将在 qm.ini 中包含以下所有内容：
TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0
但是，任何已升级的队列管理器在默认情况下都不会获得这些设置，这意味着如果这些设置不存在，它们将不会被添加，如果它们存在，它们将保持不变。如果设置不存在，那么如上所述 "the IBM MQ default, 32768, is used."
我就此主题与 IBM 支持人员进行了广泛讨论，得出的结论是，他们没有看到不将其设置为 0 的任何理由，他们只看到这样做的好处，但他们这样做时非常谨慎不会为您将其更改为 0。
我建议您将所有这些添加到您的 qm.ini，但至少添加我上面突出显示的两个。
这些设置很适合实施，但如果两端最近没有任何变化，可能无法解决您的问题。但是，如果确实发生了一些变化，例如网络差异，或者 MQ 在远程端升级到 8.0.0.8，那么此设置可能会解决您的问题。
在通道状态输出中有两个值很有趣：
NETTIME(2789746,3087573)XQTIME(215757414,214033427)
NETTIME 表示根据最近 activity 从 RCVR 通道接收响应需要 2.7 秒，在更长的时间内从 RCVR 通道接收响应需要 3.1 秒。您能否将此与从发送通道服务器到接收通道服务器的 TCP ping 进行比较，2.7 秒的网络响应时间似乎过长。在演示 Keeping MQ Channels Up and Running given at Capitalware's MQ Technical Conference v2.0.1.4 中，曾在 IBM 工作的 Paul Clarke 表示“NETTIME 仅测量网络时间，不包括
例如 MQCMIT。
XQTIME 表示根据最近的 activity 和更长的时间，XMITQ 上的消息被 SDR 通道接收到发送需要大约 215 秒。
请参阅下文了解 IBM 如何记录这些内容：
NETTIME
Amount of time, displayed in microseconds, to send a request to the remote end of the channel and receive a response. This time only measures the network time for such an operation. Two values are displayed:
- A value based on recent activity over a short period.
- A value based on activity over a longer period.
XQTIME
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
- A value based on recent activity over a short period.
- A value based on activity over a longer period.
有关 BATCHSZ 通道参数的信息可以在 IBM MQ v8.0 知识中心页面 Reference>Configuration reference>Channel attributes>Channel attributes in alphabetical order>Batch size (BATCHSZ) 中找到。我引用了它并在 粗体.
中突出显示了一些区域
This attribute is the maximum number of messages to be sent before a sync point is taken.
The batch size does not affect the way the channel transfers messages; messages are always transferred individually, but are committed or backed out as a batch.
To improve performance, you can set a batch size to define the maximum number of messages to be transferred between two sync points. The batch size to be used is negotiated when a channel starts, and the lower of the two channel definitions is taken. On some implementations, the batch size is calculated from the lowest of the two channel definitions and the two queue manager MAXUMSGS values. The actual size of a batch can be less; for example, a batch completes when there are no messages left on the transmission queue or the batch interval expires.
A large value for the batch size increases throughput, but recovery times are increased because there are more messages to back out and send again. The default BATCHSZ is 50, and you are advised to try that value first. You might choose a lower value for BATCHSZ if your communications are unreliable, making the need to recover more likely.
This attribute is valid for channel types of:
- Sender
- Server
- Receiver
- Requester
- Cluster sender
- Cluster receiver
跟进问题：
- PUT 到此 XMITQ 的消息是否持久？
答：是的，在我们的 PROD 环境中，所有消息都是持久的。
- 最近进入此 XMITQ 的流量是否有所增加？
答：没有，我们使用了一个监控工具，我们提取了一份报告，显示这段时间内的消息率非常相似。过去 2 周的比率相同。
- 放置应用程序是否设置
MQPMO_SYNCPOINT，然后在将 1 条或多条消息 PUT 到队列后提交？
答：我会与申请团队核实。
几件事..
- 您有 XBATCHSZ(1,1)，因此您最近的批量大小是每批 1 条消息。
- 消息总数 23505 批次 403，因此平均每批次有 58 条消息。如果你最近的批量大小是 1，那么你一定有一些更大的（100？）批量大小
- XQTIME 191225 是消息在发送前在 xmit queue 上的微秒数。这是0.1秒！
- 网络时间 101563 微秒。这是一个很长的时间（0.1 秒）10,000 将是一个很好的价值。将其与“TCP PING”进行比较
- BUFSSENT 23525 类似于消息数 - 因此消息大小通常低于 32K。字节流。 messages给出了2286条这么小的消息。
要检查的事情
- 远端的queue。填满了吗？这会导致发件人 queue 收到更多消息
- 网络时间似乎很长。将此与 TCP Ping 进行比较。 Nettime 可以在远程端包含慢速 IO - 或者在远程端 queue 满
- XQTIME 高。这可能是由于发送应用程序未提交或磁盘 IO 速度慢
我写了"Why is my xmit queue filling up" in this blog
*搜索标题
读一读。
在一天内捕获这些指标，看看它们是否典型
问候
科林·佩斯
我们一直面临一个问题，即 xmitq 的消息速率与正常性能相比非常慢。 我们有许多其他具有更大 MQ 流的 Qmgr 没有同样的问题。
我们的HUB qmgr连接到同一个公司HUB qmgr的业务线，连他们这边的destination queue都是空的，流量真的很慢。
在 OS 和网络级别，他们说无能为力。在 MQ，我们更改了缓冲区大小，使其匹配 OS 级别并使用系统 tcp windows.
现在在 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)
我会在这个答案中提出一些意见，但根据任何进一步的反馈，我可能会添加更多内容。
你是 运行 发送方软件的一个非常旧的版本，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, and SPX:
SvrSndBuffSize=32768|number
The size in bytes of the TCP/IP send buffer used by the server end of a client-connection server-connection channel.SvrRcvBuffSize=32768|number
The size in bytes of the TCP/IP receive buffer used by the server end of a client-connection server-connection channel.
在 IBM MQ v7.5.0.2 APAR IV58073 中引入了将各种缓冲区设置设置为 0 的概念，这意味着它将允许使用操作系统默认值。不幸的是，与知识中心中的许多内容一样，IBM 似乎没有为 7.5 正确记录这一点。
但是，您可以查看 IBM MQ v8.0 知识中心，以在页面 Configuring>Changing configuration information>Changing queue manager configuration information>TCP, LU62, and NETBIOS 上全面了解这些设置，特别是您希望设置这两个设置以对您的发件人产生任何影响频道：
SndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sending end of channels. This stanza value can be overridden by a stanza more specific to the channel type, for example RcvSndBuffSize. If the value is set as zero, the operating system defaults are used. If no value is set, then the IBM MQ default, 32768, is used.RcvSndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sender end of a receiver channel. If the value is set as zero, the operating system defaults are used. If no value is set, then the IBM MQ default, 32768, is used.
从 IBM MQ v8.0 开始，任何新创建的队列管理器都将在 qm.ini 中包含以下所有内容：
TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0
但是，任何已升级的队列管理器在默认情况下都不会获得这些设置，这意味着如果这些设置不存在，它们将不会被添加，如果它们存在，它们将保持不变。如果设置不存在，那么如上所述 "the IBM MQ default, 32768, is used."
我就此主题与 IBM 支持人员进行了广泛讨论，得出的结论是，他们没有看到不将其设置为 0 的任何理由，他们只看到这样做的好处，但他们这样做时非常谨慎不会为您将其更改为 0。
我建议您将所有这些添加到您的 qm.ini，但至少添加我上面突出显示的两个。
这些设置很适合实施，但如果两端最近没有任何变化，可能无法解决您的问题。但是，如果确实发生了一些变化，例如网络差异，或者 MQ 在远程端升级到 8.0.0.8，那么此设置可能会解决您的问题。
在通道状态输出中有两个值很有趣：
NETTIME(2789746,3087573)XQTIME(215757414,214033427)
NETTIME 表示根据最近 activity 从 RCVR 通道接收响应需要 2.7 秒，在更长的时间内从 RCVR 通道接收响应需要 3.1 秒。您能否将此与从发送通道服务器到接收通道服务器的 TCP ping 进行比较，2.7 秒的网络响应时间似乎过长。在演示 Keeping MQ Channels Up and Running given at Capitalware's MQ Technical Conference v2.0.1.4 中，曾在 IBM 工作的 Paul Clarke 表示“NETTIME 仅测量网络时间，不包括 例如 MQCMIT。
XQTIME 表示根据最近的 activity 和更长的时间，XMITQ 上的消息被 SDR 通道接收到发送需要大约 215 秒。
请参阅下文了解 IBM 如何记录这些内容：
NETTIME
Amount of time, displayed in microseconds, to send a request to the remote end of the channel and receive a response. This time only measures the network time for such an operation. Two values are displayed:
- A value based on recent activity over a short period.
- A value based on activity over a longer period.
XQTIME
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
- A value based on recent activity over a short period.
- A value based on activity over a longer period.
有关 BATCHSZ 通道参数的信息可以在 IBM MQ v8.0 知识中心页面 Reference>Configuration reference>Channel attributes>Channel attributes in alphabetical order>Batch size (BATCHSZ) 中找到。我引用了它并在 粗体.
This attribute is the maximum number of messages to be sent before a sync point is taken.
The batch size does not affect the way the channel transfers messages; messages are always transferred individually, but are committed or backed out as a batch.
To improve performance, you can set a batch size to define the maximum number of messages to be transferred between two sync points. The batch size to be used is negotiated when a channel starts, and the lower of the two channel definitions is taken. On some implementations, the batch size is calculated from the lowest of the two channel definitions and the two queue manager MAXUMSGS values. The actual size of a batch can be less; for example, a batch completes when there are no messages left on the transmission queue or the batch interval expires.
A large value for the batch size increases throughput, but recovery times are increased because there are more messages to back out and send again. The default BATCHSZ is 50, and you are advised to try that value first. You might choose a lower value for BATCHSZ if your communications are unreliable, making the need to recover more likely.
This attribute is valid for channel types of:
- Sender
- Server
- Receiver
- Requester
- Cluster sender
- Cluster receiver
跟进问题：
- PUT 到此 XMITQ 的消息是否持久？
答：是的，在我们的 PROD 环境中，所有消息都是持久的。 - 最近进入此 XMITQ 的流量是否有所增加？
答：没有，我们使用了一个监控工具，我们提取了一份报告，显示这段时间内的消息率非常相似。过去 2 周的比率相同。 - 放置应用程序是否设置
MQPMO_SYNCPOINT，然后在将 1 条或多条消息 PUT 到队列后提交？
答：我会与申请团队核实。
几件事..
- 您有 XBATCHSZ(1,1)，因此您最近的批量大小是每批 1 条消息。
- 消息总数 23505 批次 403，因此平均每批次有 58 条消息。如果你最近的批量大小是 1，那么你一定有一些更大的（100？）批量大小
- XQTIME 191225 是消息在发送前在 xmit queue 上的微秒数。这是0.1秒！
- 网络时间 101563 微秒。这是一个很长的时间（0.1 秒）10,000 将是一个很好的价值。将其与“TCP PING”进行比较
- BUFSSENT 23525 类似于消息数 - 因此消息大小通常低于 32K。字节流。 messages给出了2286条这么小的消息。
要检查的事情
- 远端的queue。填满了吗？这会导致发件人 queue 收到更多消息
- 网络时间似乎很长。将此与 TCP Ping 进行比较。 Nettime 可以在远程端包含慢速 IO - 或者在远程端 queue 满
- XQTIME 高。这可能是由于发送应用程序未提交或磁盘 IO 速度慢
我写了"Why is my xmit queue filling up" in this blog
*搜索标题
读一读。
在一天内捕获这些指标，看看它们是否典型
问候
科林·佩斯