| Author |
Message
|
| hdjur |
 Posted: Fri Nov 04, 2005 8:26 am Post subject: sender channel too slow |
 |
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hello!
Transmission queue depth grows because sender channel is too slow, and putting application is fast. Display qstatus says that runmqchl process opens transmission queue in INPUT(EXCL) mode. Is it possible to configure sender channels to open transmission queues in shared mode, and to add another instance of sender channel to handle the same xmitq? Network does not create bottleneck in the system, so I assume maybe two processes will do the job faster than one? If that's not the case what would be the usual way to handle the situation?
Thanks in advance. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Fri Nov 04, 2005 8:42 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
No, you can't do that anymore. Only one channel instance per xmitq.
But ... you can have that one instance use two threads for moving messages. Lookup "pipelining" in the Infoctr.
(Who remembers the CICS Message Mover? You could have multiple channels reading the same xmitq).
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Nov 05, 2005 4:03 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Also check parameters BATCHSZ, BATCHTMR - these can increase your channel throughput by up to 500% easy. You should also check to see if your QMs and your runmqchl's receive appropriate OS priorities.Keep us posted.
(p.s Wayne - don't forget, as i'm sure you didn't, the unique case of clustering. As for the CICS Mover, i'd personally rather forget  ) |
|
| Back to top |
|
|
| wschutz |
| Posted: Sun Nov 06, 2005 4:17 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Hopsala, yes, of course, i should have mentioned the cluster channel case ... 
BTW... whats is BATCHTMR? (BATCHINT?)
Also, with MQ V6 we now have:
| Quote: |
Is the network slow?
If messages are not moving fast enough across a channel, this could be because the network is slow. To identify if this is the case, do the following:
1. In the output of the command DIS CHSTATUS(QM1.TO.QM2) ALL, check the NETTIME field.
These indicators are measured when the sending channel asks its partner for a response. This happens at the end of each batch and, when a channel is idle during heartbeating.
2. If this indicator shows that round trips are taking longer than expected, use other network monitoring tools to investigate the performance of your network. |
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 06, 2005 10:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hopsala wrote: |
| You should also check to see if your QMs and your runmqchl's receive appropriate OS priorities. |
How?
For instance, on my Windows WB-IMB Brokers, during heavy batch cycles, the Execution Groups take all the CPU, leaving the RCVR channels gasping, and incoming SNDR channels start to back up. Is there any easy way to tell the OS to give amqrmppa.exe priority over dataflowengine.exe?
Wayne, to take advantage of NETTIME, do both sides of the channel need to be 6.0? (I suspect yes?)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Nov 06, 2005 10:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Task Manager lets you adjust priority for processes. Right click on the process in the Processes tab (not the applications tab) and "Set Priority".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Sun Nov 06, 2005 2:41 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Wayne, to take advantage of NETTIME, do both sides of the channel need to be 6.0? (I suspect yes?) |
I haven't tested it out (but I will tomorow), but I don't see why both ends would need to be V6. Only the end collecting the stat would have to be (imho) since it's only timing how long it has to wait before getting an ack back.
_________________
-wayne |
|
| Back to top |
|
|
| hdjur |
| Posted: Mon Nov 07, 2005 1:12 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Hello!
I have noticed this feature (NETTIME field in the output of dis chstatus) in the 6.0 documentation, unfortunately, both my ends are v5.3, so I will have to rely on the info from my network admin. I will also follow the hint regarding BATCH parameters, pipelining, OS priority of runmqchl process, study a little bit more clustering, and report results.
Thanks for your suggestions.
Hrvoje |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Nov 07, 2005 3:02 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Pipelning will not make any difference unless there is latency when the batch is completed waiting for the commit to complete at the receiver and return the confirm flow. |
How do we know this isn't the case?
_________________
-wayne |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Nov 07, 2005 3:39 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
when the sender is queueing up on the xmitq it can also be a problem at the receiving end. we sometimes see this situation with some of our customers when the receiving machine is very busy or looping or or.
in that case, the receiving end needs very long time to take and store and commit the messages, thats why the messages pile up at the senders end.
so it is not always a networking issue. btw: if you know the bandwidth of the line and you know the size of the messages (or take the bytes from the channel status) you can compute if all of the bandwidth is used or not.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ramires |
| Posted: Mon Nov 07, 2005 4:34 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
as Mr Butcher says the problem can be at the receiving side. I had that kind of problems and the solution was to modify MRRTY and MRTMR. They control the deliver of the message to the rigth queue.
Regards |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Nov 07, 2005 5:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mquseless wrote: |
| Add another channel (or 2,3,..) and send msgs over all the channels not just one. |
Would you care to provide specific steps to do this, that would not require changes to the applications?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Nov 07, 2005 6:41 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| Wayne, to take advantage of NETTIME, do both sides of the channel need to be 6.0? (I suspect yes?) |
Peter, I gave this a quick test, and confirm that you do not need v6 at both ends, only the end when you want to display the NETTIME status.
_________________
-wayne |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Nov 07, 2005 6:46 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
* create another queuemanager on the same machine
* send data to that queuemanager
* have a channel exit on the new queuemanager that changes the targetqueuemanager for the incoming messages to multiple names
* have a xmitq (or qmgr alias pointint to xmitq) for every changed qmgrname
okay, its crap, but it works (kids, do not try this at home!)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 07, 2005 10:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| wschutz wrote: |
| Quote: |
| Wayne, to take advantage of NETTIME, do both sides of the channel need to be 6.0? (I suspect yes?) |
Peter, I gave this a quick test, and confirm that you do not need v6 at both ends, only the end when you want to display the NETTIME status. |
Huh, I looked at all my 6.0 QMs, which all send to 5.3 QMs, and the NETTIME attribute in MO71 and runmqsc is showing as zeros. Since its displayed in microseconds, there is no way that can be correct. Does something else need to be turned on? A search on NETTIME in all the 6.0 manuals did not indicate anything else was needed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
