| Author |
Message
|
| mikeHT |
 Posted: Wed Apr 19, 2006 6:23 am Post subject: Cause and fix for high count of OPPROCS when doing dis qs |
 |
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
I see lots of open handles (OPPROCS) against the system.cluster.transmit.queue. Application(s) put to remote clustered queue alias.
dis qs(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8450: Display queue status details.
QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) IPPROCS(2)
OPPROCS(169) CURDEPTH(0) UNCOM(NO)
I did another dis qs this morning and here is the log:
dis qs(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8450: Display queue status details.
QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) IPPROCS(1)
OPPROCS(184) CURDEPTH(0) UNCOM(NO)
dis qs(SYSTEM.CLUSTER.TRANSMIT.QUEUE) type(handle) all
displays a long list of application pids, some which are duplicate, some are displayed several times (I once counted 13 times)
My question is if OPPROCS shows high number would that impact system resources and what I should look for in the applications' codes to resolve the high number of handles against SCTQ? Thank you. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Wed Apr 19, 2006 6:49 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Why is this a concern? Might you have a lot of applications putting messages to clustered objects?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 19, 2006 6:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would only consider it a concern if there were no IPPROCS and the CURRDEPTH was > 0.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikeHT |
| Posted: Wed Apr 19, 2006 7:23 am Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
| IBM MQ support ( 1-800-IBMSERV ) was concerned about the highcount. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 19, 2006 7:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In what context?
Will you share the PMR #?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Apr 19, 2006 7:36 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| mikeHT wrote: |
| IBM MQ support ( 1-800-IBMSERV ) was concerned about the highcount. |
Did you open a PMR for this "problem" or was it a different problem?
In any case, if you think the number is high, then you need to see what application have the queue open and work with the developers to understand the counts.
_________________
-wayne |
|
| Back to top |
|
|
| mikeHT |
| Posted: Wed Apr 19, 2006 8:36 am Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
48296,487
The issue was about messages stuck in SCTQ (mqseries.net topicid 28164) and was resolved after fixing the network duplex setting between the QMGRs. During the investigation, IBM support was concerned with the high OPPROCS count and that application developer should be involved. But what should I ask developer to look into? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Apr 19, 2006 9:11 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
for example:
| Quote: |
| pids, some which are duplicate, some are displayed several times (I once counted 13 times) |
Okay, is that PID an application program? If so, is it expected that the program has 13 connections to the qmgr?
_________________
-wayne |
|
| Back to top |
|
|
| mikeHT |
| Posted: Wed Apr 19, 2006 9:59 am Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
| The PID is for 1 application program which polls to check that remote clustred queue alias is present. The 13 instances of PID(11984) when doing dis qs(SCTQ) type(handle) all. That is caused by the application putting to the remote clustered queue alias which consequently caused the OPPROCS counts on the SCTM. But why after the application put to SCTM, we don't see the OPPROCS count go to 1 in this case? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Apr 19, 2006 11:08 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| The PID is for 1 application program which polls to check that remote clustred queue alias is present. |
I'd ask why the application needs to do that...I wouldn't normally expect applications to query for queue's being present.
| Quote: |
| The 13 instances of PID(11984) when doing dis qs(SCTQ) type(handle) all. That is caused by the application putting to the remote clustered queue alias which consequently caused the OPPROCS counts on the SCTM |
I'd suspect a programming error here.... is it creating connections to the qmgr for each message being put and then not releasing them?
_________________
-wayne |
|
| Back to top |
|
|
| mikeHT |
| Posted: Wed Apr 19, 2006 12:22 pm Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
| wschutz wrote: |
| Quote: |
I'd ask why the application needs to do that...I wouldn't normally expect applications to query for queue's being present.
|
The application is checking if remote cluster queue alias is available for put. If the remote cluster queue alias is not available, get the following error thrown to application log. Application log fills up very quickly because it polls every 10th of a sec
The description for Event ID ( 0 ) in Source ( amqmdnet ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: EXCEPTION 1: IBM.WMQ.MQException
Error in the application.
******************** STACK TRACE ********************
at IBM.WMQ.MQQueue..ctor(MQQueueManager qMgr, String queueName, Int32 openOptions, String queueManagerName, String dynamicQueueName, String alternateUserId)
at IBM.WMQAX.MQQueueManager.AccessQueue(String queueName, Int32 openOptions, String queueManagerName, String dynamicQueueName, String alternateUserId)
at IBM.WMQAX.MQQueueManager.AccessQueue(String queueName, Int32 openOptions)
at APP.MQManagement.QueueManager.Open(String paramFile, String openAppId) in C:\APP\SRC\Common\Objects
******************** EXCEPTION PROPERTIES ********************
ReasonCode: 2189
Reason: 2189
CompletionCode: 2
CompCode: 2
TargetSite: Void .ctor(IBM.WMQ.MQQueueManager, System.String, Int32, System.String, System.String, System.String)
Source: amqmdnet
--------------------------------------------------------------------------------------------------------
| Quote: |
| The 13 instances of PID(11984) when doing dis qs(SCTQ) type(handle) all. That is caused by the application putting to the remote clustered queue alias which consequently caused the OPPROCS counts on the SCTM |
I'd suspect a programming error here.... is it creating connections to the qmgr for each message being put and then not releasing them? |
I'm suspecting that is what is happening but I don't have MQ develop experience. The codes are in VB .NET and they are using: Imports IBM.WMQAX & Imports IBM.WMQ.MQC. What should I be looking for in the codes to find that the application is not properly releasing the connections to the qmgr or remote cluster queue alias? Thank you. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Apr 19, 2006 4:02 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| mikeHT |
| Posted: Thu Apr 20, 2006 1:15 pm Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
Developers are using MQ's Component Object Model Interface (IBM.WMQAX, IBM.WMQ.MQC)
Is it true to say that there need to be a MQQueueManager::Disconnect for each MQAXSession::AccessQueueManager?
For one instance mq trace, I counted 62 MQAXSession::AccessQueueManager and only 50 MQQueueManager::Disconnect.
Is that the reason for the high OPPROCS count? If that is the cause, I'll ask the developers to check their code for calling MQQueueManager::Disconnect for each MQAXSession::AccessQueueManager
Thank you. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 20, 2006 1:40 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
you've got it.
They should also be closing each q as well (although they get an implicit close of the queues if they dosconnect that QM, its cleaner to explicitly close the q)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mikeHT |
| Posted: Tue May 16, 2006 8:22 am Post subject: |
|
|
Voyager
Joined: 01 Jul 2005
Posts: 82
|
| Still trying to get the developer to issue the disconnect explictly, when the applications reset because they did not complete. Is there a MAX OPPROCS count which could cause MQ Queue manager to crash or act funny? Lots of OPPROCS against lqeueus eat up on system resource right? Thanks |
|
| Back to top |
|
|
|
|
