| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MIPS consuming rate is very high for CHIN address space |
« View previous topic :: View next topic » |
| Author |
Message
|
| sumansengupta07 |
 Posted: Wed Nov 05, 2014 10:21 pm Post subject: MIPS consuming rate is very high for CHIN address space |
 |
|
Novice
Joined: 14 Nov 2013
Posts: 23
|
From last couple of days, we have been observing in our Mainframe system that MQ CHIN address space is consuming huge amount of MIPS. Could anyone please tell me the possible reason behind this?
 |
|
| Back to top |
|
 |
| MQsysprog |
| Posted: Thu Nov 06, 2014 1:56 am Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
Hello,
I would start with the workload of the channel init ,for example if new channels have been added recently ,and in general on the size of the messages handled by the channels inbound and outbound .
Then an analysis of the numbers of channels in retry state and
a display of the number of messages in the system.channel.syncq
may be useful ,remembering that this queue must be indexed by msgid and on a dedicated buffer pool and pageset, ideally not on the pageset 0 . |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Nov 06, 2014 12:17 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| One possibility is that you have something configured incorrectly that could be causing a message to bounce constantly between queue managers. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 06, 2014 12:51 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Anything unusual or relevant in the CHIN syslog?
_________________
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 |
|
|
| sumansengupta07 |
| Posted: Sat Nov 08, 2014 8:55 am Post subject: |
|
|
Novice
Joined: 14 Nov 2013
Posts: 23
|
First, we didn't change any configuration in the QMGR since very long. Second, we also can't see any unusual thing in the CHIN log.
And the MIPS consumption rate of the CHIN address space is not same for all the day....sometime it takes huge amount of MIPS like 85...sometime it takes normal like 45. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 08, 2014 5:26 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| sumansengupta07 wrote: |
First, we didn't change any configuration in the QMGR since very long. Second, we also can't see any unusual thing in the CHIN log.
And the MIPS consumption rate of the CHIN address space is not same for all the day....sometime it takes huge amount of MIPS like 85...sometime it takes normal like 45. |
You need to do some data gathering. Are you capturing SMF data for your CHIN?
What version of z/os? What wersion of MQ? At both ends of the channel? z/os at both ends of the channel?
How many channels? And what kind of channels? How many are active during these times? What message sizes?
You say nothing has changed. Absolutely nothing? Nothing new in the network? No application changes of any type? No changes to resources in the LPAR?
How many adapters are defined for this CHIN? How many initiators? What batchsize?
How many bytes are flowing across the channels at these times?
Anything in the MSTR syslog?
_________________
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 |
|
|
| gbaddeley |
| Posted: Sun Nov 09, 2014 4:59 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Are there lots of clients connected to the qmgr? The CHIN performs all of the MQI calls on behalf of clients.
Look at channel status to identify any high volume channels.
_________________
Glenn |
|
| Back to top |
|
|
| elkinsc |
| Posted: Thu Aug 06, 2015 9:13 am Post subject: Badly behaved clients |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
If you have not suppressed them, look for the channel connect and disconnect messages in the CHIN JES log. Badly behaved clients, ones that connect do one or two things, disconnect, then reconnect repeatedly is the typical thing which drives up CHIN CPU. If the messages are suppressed, either by your system or using that option in MQ V8, then it's not going to be as obvious.
If your environment is sensitive to the CPU costs and if the problem is badly behaved clients, then they should be recoded to limit the connect/disconnect behavior. Or consider using a client concentrator queue manager running on Linux for system z or another distributed platform. Then that queue manager will absorb the CPU costs of the connects, and can maintain long running connections to the z/OS queue manager.
There are also a number of CPU related APARs floating around. How current are you on maintenance? |
|
| 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
|
|
|
|
