I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?

I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?

Tim,

You mention S.C.T.Q, are you using the actual (singular) SYSTEM.CLUSTER.TRANSMIT.QUEUE or have you enabled multiple cluster transmit queues.

If you are still using the singular S.C.T.Q then I'd probably start by removing this unnecessary serialization point. In addition to removing the performance constrains of the single queue, it also makes monitoring what's happening on this specific channel/queue a little easier. The throughput of a single channel should be pretty high, and if you enable pipelining even higher (something of the effect of multiple channels). What does sampling the channel substate during the issue suggest (at both the sending and receiving end)  might be the limiting factor ? Are the values for NETTIME within the expected boundaries ? Is the IO latency on the recovery log (at each end of the channel) reasonable (assuming persistent messages), ...

Similarly, there seems to be an assumption that the issue is at the sending end of the channel, while it's equally likely that the issue is with the putting end of the channel not being able to deliver the messages fast enough. Are all of most of these messages going to the same destination queue, or are they spread about across a set of queues. Have you check for any performance issues on the queues to which the messages are being delivered.

The absence of any actual numbers and details of the environment in which the issue is being observed makes it difficult to offer properly targetted advice.

Regards

Andy.

I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?

I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?

Are QM1 and QM2 on similarly provisioned hardware platforms?  If QM1 is on z hardware, for example, and QM2 is on lesser provisioned midrange hardware, QM2 (cluster)receiver channel is likely overwhelmed.

I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?

Thank you all for the helpful tips! The SCTQ build up has not happened for a while, but this will help in better diagnosing the issue if/when it happens again. 

Are QM1 and QM2 on similarly provisioned hardware platforms?  If QM1 is on z hardware, for example, and QM2 is on lesser provisioned midrange hardware, QM2 (cluster)receiver channel is likely overwhelmed.

I have a scenario where I am seeing S.C.T.Q. backups between QM1 -> QM2. The messages are in a cluster and flowing over one instance of a CLUSSDR channel (e.g. CLUS.QM2). The QM2 only has one CLUSRCVR channel for the cluster, per standards for clustering. If I was to define another CLUSRCVR channel on QM2 (e.g. CLUS2.QM2), I would assume QM1 could then run 2 CLUSSDR channels (CLUS.QM2 and CLUS2.QM2) to QM2. However, I had some questions.

1) Is this not a good idea to have two CLUSRCVR channels for the same cluster on a queue manager? I did some manual research and only found a concern about how it can hurt performance with channel switching for lower volume messages. But I am really more concerned about addressing high volume of messages and moving the messages through the S.C.T.Q. at a faster rate.

2) Has anyone else used this approach and found it helpful?