| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Delay in delivery of messages to clustered queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Tue Nov 10, 2020 2:40 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Just an observation:
| Quote: |
MQ Version:
A:9.0.0.8
B: 9.0.0.9
APP1 & APP2: 9.0.0.5
FR1 & FR2: 9.0.0.5 |
IBM recommends that FR queue managers should be at the highest level in any cluster; Knowledge Centre Article extract below (my emphasis):
"...A partial repository reflects whichever full repository sent it the latest update to a record. As a consequence, you might see the information held by an IBM MQ 9.0 partial repository for new IBM MQ 9.0 attributes changing unexpectedly. The values might change from actual IBM MQ 9.0 information to default values. The changes occur if the full repositories in the cluster are at different levels. Migrate full repositories first to avoid instability..."
_________________
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 |
|
 |
| gbaddeley |
| Posted: Tue Nov 10, 2020 3:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
I suggest having a closer look at the server where QMC3 is running. It appears something is intermittently impacting the performance of MQ for about 2 seconds, and then MQ quickly catches up with processing the SCTQ in the next 2 seconds.
_________________
Glenn |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Nov 10, 2020 9:13 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| rujova wrote: |
I am tempted to increase the XBATCHSZ, but in the KC it indicates that it can have a negative impact by delaying the first messages placed in the batch waiting for a commit. I also found old threads that talk about the topic. I don't know what other parameter or configuration could help us reduce those timeout peaks.  |
You've told us that your messages are non-persistent, so the comment about waiting for a commit does not apply, as non-persistent messages are moved over a channel outside of a transaction (unless you have changed NPMSPEED which I suspect is unlikely).
Do you have some evidence that you haven't mentioned that suggests line turn-around is playing a part in these patterns? Or do you have some other reason for considering increasing the BATCHSZ?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 11, 2020 8:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Even though your messages are non persistent, it might be of benefit to reset the channel sequence number where you experience the delays...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 11, 2020 11:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hughson wrote: |
| ... (unless you have changed NPMSPEED which I suspect is unlikely). |
What is the NPMSPEED setting on both ends of the channel? The CLUSRCVR channel def for NPMSPEED will determine the CLUSSDRA/B value.
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Jun 23, 2021 6:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| rujova wrote: |
| The networking team tells us that everything is fine ... |
I'm not reassured. I've been lied to before.
If the servers are equally provisioned, but one of them is misbehaving, then it must be something about the misbehaving server.
I'll speculate that you have a misbehaving NIC card at the receiving end of the channel. Look at receiving end TCPIP, MQ and qmge error logs.
_________________
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 |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
