| Author |
Message
|
| visitraja |
 Posted: Wed Oct 17, 2012 10:16 pm Post subject: Messages from SCTQ are processing very slow |
 |
|
Novice
Joined: 08 Feb 2012
Posts: 14
|
Hi,
We had MQ cluster where the client loads to the queue on the gateway QM and from which they gets transferred to a cluster member for processing(MB) and transfers back to Gateway QM from where the client picks the responses.
This setup has been working for almost 4 yrs now.
Recently we applied MQ FP which we from MQ V6.0.2.1 to MQ V6.0.2.9 (This change is working normally in lower environments)
After this we are encountering the problem where Messages from SCTQ are processing very slow in fact they were getting piled up as the put rate is faster than get rate.
Message are put through some batch job where the load is similar to what we had earlier.
The problem looks like the "syncpoint commit" is not happening . MQ is rolling back the transaction with the error - the log space is getting filled. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Oct 17, 2012 10:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well, looks like you may have 2 different problems there.
One you have diagnosed admirably, the other (slowness of messages on xmitq) is probably caused by a queue full on the destination side.
Find the offending queue on the destination side and have it services.
Note that with the commit of your batch the queue full on the destination can be instantaneous. Make sure the queue has enough depth to handle the batch. Make sure the batch commits often enough.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| visitraja |
| Posted: Wed Oct 17, 2012 11:08 pm Post subject: |
|
|
Novice
Joined: 08 Feb 2012
Posts: 14
|
Thanks FJB
The destination Queue is not full infact no messages are left there for application to pick them.
When the transactions are backed up then I can see some "error/ghost" messages landing up in the SCTQ , not sure if they are the one that's creating problem or are they are the result of the "backup" due to log space.
However , all the mesages are getting cleared after the QMGR restart and the pileup/backlog of messages continue after the restart. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Oct 17, 2012 11:55 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You're on an out-of-support version of WMQ, and even your FixPack level is behind the drag curve as FP12 was the last for V6.0, and your logging is insufficient to deal with the messages. Before you restarted the queue manager did you increase the number of available logs?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| visitraja |
| Posted: Thu Oct 18, 2012 4:23 am Post subject: |
|
|
Novice
Joined: 08 Feb 2012
Posts: 14
|
exerk,
yes may be its a legacy infrastructure, as I told you we are running on that from the past 4 yrs. We got the extended Support. we are planning to move to V7.5.
No we haven't tried to increase logs. I am not able to understand what are happening to these messages that are before restart , are they getting processed? or thay are getting purged. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 18, 2012 4:37 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| visitraja wrote: |
| No we haven't tried to increase logs. |
Yet you clearly have an issue with logs filling and messages being rolled back. You should consider increasing your logs if only to give yourself breathing space while you sort out the root cause.
| visitraja wrote: |
| I am not able to understand what are happening to these messages that are before restart , are they getting processed? or thay are getting purged. |
Trap a message, either on the S.C.T.Q or the target queue, and examine its MQMD. That will tell you whether messages are persistent or not, and therefore answer your question as to whether they're being purged or not.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| visitraja |
| Posted: Fri Oct 19, 2012 1:51 am Post subject: |
|
|
Novice
Joined: 08 Feb 2012
Posts: 14
|
I think we had a solution, the reduction in cluster channel batch size did the trick for committing messages more frequently.
But couldn't completely understand how batchsize Vs loggersize values for messages transfer. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 19, 2012 3:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Messages are sent across a channel in batches. Batchsize specifies how many messages comprise a batch. Batchinterval specifies how long the MCA should wait for a complete batch (batchsize) to arrive in the xmitq before sending the message(s).
Try setting batchinterval to zero.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
