| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ stats compare |
« View previous topic :: View next topic » |
| Author |
Message
|
| zrux |
 Posted: Thu Apr 03, 2025 12:37 am Post subject: MQ stats compare |
 |
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
seeing an interesting issue
Scenario
MQ System A is splitting the traffic to 2 environments say (B and C) via MQ PUB/SUB
We got stats collection enabled on all the 3 systems.
The xmitq stats shows the same number of messages transferred from A to B, and A to C
When I look at the stats individually B and C, they differ vastly. System C is receiving 4 times more traffic then B.
I don't see messages going to DLQ, and any errors on the MQ error logs on either of the 3 system.
The XMITQs are clear of messages from Q going to both B and C
additionally doing a
dis chs() ALL
the CHSTADA, CHSTATI are same and so is MSG almost same.
What could be the issue and how could I identify where the issue is.
There seems to be a backlog sending the data to B.
NETTIME, XQTIME - dont see an issue
AMQ8417I: Display Channel Status details.
CHANNEL(A.B) CHLTYPE(SDR)
BATCHES(4 BATCHSZ(50)
BUFSRCVD(49) BUFSSENT(2637)
BYTSRCVD(1612) BYTSSENT(13249934)
CHSTADA(2025-04-03) CHSTATI(11.38.36)
COMPHDR(NONE,NONE) COMPMSG(ZLIBHIGH,ZLIBHIGH)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(removed(removed)) CURLUWID(217AD26731620113)
CURMSGS(0) CURRENT
CURSEQNO(8506615) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(00004F6900000001) LOCLADDR(10.65.32.108(42704))
LONGRTS(999999999) LSTLUWID(217AD26730620113)
LSTMSGDA(2025-04-03) LSTMSGTI(12.17.00)
LSTSEQNO(8506615) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(231)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(MXIBRDP1) SHORTRTS(10)
SECPROT(NONE) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(MQGET) XBATCHSZ(0,0)
XMITQ(MXIBRDP1.PNR) XQTIME(0,0)
RVERSION(08000007) RPRODUCT(MQMM)
AMQ8417I: Display Channel Status details.
CHANNEL(A.C) CHLTYPE(SDR)
BATCHES(55) BATCHSZ(50)
BUFSRCVD(57) BUFSSENT(2645)
BYTSRCVD(2076) BYTSSENT(13250398)
CHSTADA(2025-04-03) CHSTATI(11.37.45)
COMPHDR(NONE,NONE) COMPMSG(ZLIBHIGH,ZLIBHIGH)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(removed(removed)) CURLUWID(217AD26738610113)
CURMSGS(0) CURRENT
CURSEQNO(9561) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(00002AE300000001) LOCLADDR(10.65.32.108(32940))
LONGRTS(999999999) LSTLUWID(217AD26737610113)
LSTMSGDA(2025-04-03) LSTMSGTI(12.16.59)
LSTSEQNO(9561) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(231)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(MXIBRDP1) SHORTRTS(10)
SECPROT(NONE) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(MQGET) XBATCHSZ(0,0)
XMITQ(MXIBRDP1.PNR.PNR3) XQTIME(0,0)
RVERSION(09040006) RPRODUCT(MQMM)
Could slowness of network in one of the downstream system cause this difference ? The network engineer says he doesn't see any saturation on the network to B |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Apr 03, 2025 8:08 am Post subject: Re: MQ stats compare |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zrux wrote: |
NETTIME, XQTIME - dont see an issue |
NETTIME and XQTIME should be greater than zero.
Do a display channel status again - this time specify SAVED.
_________________
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 |
|
|
| zrux |
| Posted: Thu Apr 03, 2025 9:47 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
| Thanks, with the SAVED option, what do I need to look at specifically please? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 03, 2025 10:22 am Post subject: Re: MQ stats compare |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zrux wrote: |
| When I look at the stats individually B and C, they differ vastly. System C is receiving 4 times more traffic then B. |
What metric are you using? Both of our sender channels delivered exactly 231 messages.
What do you see in your displays of chstatus that differ vastly? Where do you see four times more traffic?
Are you saying that delivery of 231 messages took 30 seconds on one channel, but 2 seconds on the other channel?
NETTIME and XQTIME should be greater than zero. XQTIME is time in transmission queue waiting for messages to be transmitted. NETTIME is time on network transmitting the messages.
| zrux wrote: |
| Could slowness of network in one of the downstream system cause this difference ? The network engineer says he doesn't see any saturation on the network to B |
Yes, one busy channel or misbehaving nic card can cause network delay symptoms. Network engineers have lied to me throughout my career.
You have not offered any specific symptoms of network delay. I ask again: what metric are you using? What are you seeing? Are uend-sers complaining? Complaining about transaction response time?
_________________
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 |
|
|
| zrux |
| Posted: Thu Apr 03, 2025 11:26 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006
Posts: 41
Location: UK
|
the stats that differs is on B, where the MH04 stat pack is running. Showing values of enqueue/dequeue which doesn't match from the sender end MH04 stat pack stat by a very big number. The stats do however match on system C
I don't see any other process like which could be resetting the MQ stats (enqueue/dequeue) rates.
I am now inclined to restart the MQ VM as I think there might be an issue with the stat pack not gathering the stats consistently. This is redhat VM and been running over 1 year now without restart. I know unix based systems can run for several years without the need for a restart. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 03, 2025 2:47 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Insufficient resources can result in the symptoms you see.
_________________
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 |
|
|
| fjb_saper |
| Posted: Sun Apr 06, 2025 7:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And can you please set monchl(low) or monchl(qmgr) assuming the qmgr is set to low?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Apr 25, 2025 4:27 pm Post subject: Re: MQ stats compare |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| zrux wrote: |
We got stats collection enabled on all the 3 systems.
The xmitq stats shows the same number of messages transferred from A to B, and A to C
When I look at the stats individually B and C, they differ vastly. System C is receiving 4 times more traffic then B. |
These two statements seem to contradict each other. On the one hand you say that there are the same number of messages transferred to each system and then you say that one system is receiving 4 times the traffic as the other one.
Can you tell us what stats you are looking at in both cases, and show us some of the numbers that lead you to make these seemingly contradictory statements. Perhaps they are not counting the same things, but since you don't show us the stats, we can't really help.
| zrux wrote: |
The XMITQs are clear of messages from Q going to both B and C
There seems to be a backlog sending the data to B. |
Again, these appear on the surface to be contradictory statements. Where are you seeing the backlog if the XMITQs are clear of messages? Show us the numbers that lead you to say this so that we might have a chance of helping you.
| zrux wrote: |
NETTIME, XQTIME - dont see an issue
AMQ8417I: Display Channel Status details.
CHANNEL(A.B) CHLTYPE(SDR)
MONCHL(OFF)
AMQ8417I: Display Channel Status details.
CHANNEL(A.C) CHLTYPE(SDR)
MONCHL(OFF) |
I can see from your provided Channel Status output that MONCHL is OFF, so you are not actually collecting data to be able to tell whether NETTIME or XQTIME have issues or not. If you want to know whether NETTIME or XQTIME are problematic, you must turn on MONCHL.
I look forward to being able to see the stats that you see and then maybe being able to offer some insight.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Apr 26, 2025 1:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Little of this entire post makes sense. Is this another one of those trade-school
homework assignments?
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
