| Author |
Message
|
| samsansam |
 Posted: Sat Jan 17, 2015 6:23 pm Post subject: amqzlaa0 |
 |
|
Apprentice
Joined: 19 Mar 2014
Posts: 41
|
is there way to tell amqzlaa0 is belong to which application? also,
is there way to tell if amqzlaa0 is active or hung? I see alot of amqzlaa0 in our server.
We are using MQ 7.0.1.5 on solaris boxes |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Jan 18, 2015 1:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It is the qmgr's logging process IIRC. So you should have at least one per running qmgr.
Check the command line info of the process, it should have "-m<QMGR>" in it.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 18, 2015 6:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A quick Google search resulted in this document: http://www.mqtechconference.com/sessions_v2013/MQ_Internals_DeepDive.pdf
A quick search of the document for amqzlaa0 resulted in this:
| Quote: |
•The LQM agents are program amqzlaa0 or amqzlsa0. Agents perform the operations required to process MQI calls on behalf of applications. Nearly all of the code beneath the MQI is actually executed by the agents.
‒The separation of application programs from the queue manager's critical resources protects the queue manager from rogue or malicious applications.
‒The number of agent processes depends on the workload. By default, agents each handle about 60 concurrent connections. |
If you see a lot of instances of amqzlaa0, then you must have a busy qmgr. If you applications are running successfully, then your LQMA's are working fine.
_________________
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 |
|
|
| tczielke |
| Posted: Sun Jan 18, 2015 7:15 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Also, since amqzlaa0 is processing the application connection activity into the queue manager, the DIS CONN is a good way to investigate what applications are using these agent processes. MQ accounting and statistics would be helpful in seeing what applications are driving the load. |
|
| Back to top |
|
|
| samsansam |
| Posted: Sun Jan 18, 2015 7:26 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014
Posts: 41
|
Actually, we do have very busy Queue Manager (one Queue Manager). When I grep for amqzlaa0 using th following command:-
ps -ef |grep -c amqzlaa0
the out put is 470. I know amqzlaa0 is the MQI call from App t MQ. But here what confused me.
By following what tczielke said, the out put of dis conn (*) will show 156 connections.
so how do I have 156 connections and in the same time I see 470 amqzlaa0 process.
By the way , we ave a huge memory ( 100 GB) , so no worry about the process , just want to understand.
Also, We are using MQ multi instance  |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Jan 19, 2015 12:52 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
By default, current 64-bit queue managers support 128 application threads per amqzlaa0 process, hence 470 amqzlaa0 processes suggest in the region of 5000 connections !
Dis conn only showing 156 connections suggests some sort of a leak, either in the queue manager, or in the applications.
DIS CONN shows connections to the queue manager established with an MQCONN(X), an xa_open() will also result in a thread being created in an amqzlaa0 process to act on behalf of that xa session, however unless the same thread also performs and xa_open the session won't show up in the output of DIS CONN.
I'd suggest that you should open this issue with MQ support (PMR).
The service utility amqldmpa can list the agent threads in more detail, the command
"amqldmpa -m <QMGR-NAME> -c K -f/var/mqm/errors/kern.txt"
will APPEND a report to the file /var/mqm/errors/kern.txt with details of how application threads are related to amqzlaa0 processes (amongst other things). As this is a service utility the output is not documented, and is really intended for IBM's consumption, but quite a bit of it is fairly self explanatory to someone familiar with MQ concepts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 19, 2015 5:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Don't forget to run endmqtrc -a after you're done tracing...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Jan 19, 2015 10:17 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
| amqldmpa is quite separate from MQ trace. There's no need to run endmqtrc after running amqldmpa. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 19, 2015 10:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Andyh wrote: |
| amqldmpa is quite separate from MQ trace. There's no need to run endmqtrc after running amqldmpa. |
When I ran it this morning in V8.0.0.0 on a windows 8.1 box, I could not remove the deleted .trc files from the recycle folder until I ran endmqtrc -a ...
Although I must confess I ran the command without the -f flag... and found the .trc files in <mqdata>/errors
Running it with the -f flag gives exactly the results defined by Andyh.
(no need to run endmqtrc -a ) ...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| samsansam |
| Posted: Mon Jan 19, 2015 2:26 pm Post subject: |
|
|
Apprentice
Joined: 19 Mar 2014
Posts: 41
|
Ok thank you every one for helping , one more thing, just want tom make sure if my infromation is right.
the output of amqldmpa showed some trans are :-
State ACTIVE|ASSOC|BOUND
others are :-
State PREPARED|HARDENED|LOGGED
is the prepared one hung? |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Jan 19, 2015 11:57 pm Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
A prepared transaction does not in itself consume a thread in an amqzlaa0 process.
In order to see un-associated transactions you would have had to run amqldmpa with different options, which gives the strong impression that this thread doesn't contain all the relevant information, for example who advised you to collect amqldmpa transaction information, and why.
How many connections did the amqldma -c K ... ouput show, and in what states ? That information would typically be much more pertinent to an unexpectedly large number of amqzlaa0 processes. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Jan 22, 2015 5:57 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
| Andyh wrote: |
The service utility amqldmpa can list the agent threads in more detail, the command
"amqldmpa -m <QMGR-NAME> -c K -f/var/mqm/errors/kern.txt"
will APPEND a report to the file /var/mqm/errors/kern.txt with details of how application threads are related to amqzlaa0 processes (amongst other things). As this is a service utility the output is not documented, and is really intended for IBM's consumption, but quite a bit of it is fairly self explanatory to someone familiar with MQ concepts. |
Hi Andy,
Would amqldmpa have an option to display the current qm.ini and mqs.ini attributes that the queue manager is running with? If so, would you mind sharing the option to do that? 
Regards,
Tim |
|
| Back to top |
|
|
| Andyh |
| Posted: Thu Jan 22, 2015 8:51 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
amqldmpa formats control blocks for the 'lqm' queue manager sub-components.
Where mqs.ini and qm.ini parameters (and TuningParameters, and environment variables) are transposed to these control blocks then they're implicitly formatted by amqldmpa. There's no option in amqldmpa to
summarize all of these values in one place.
For example, the amqldmpa -c H output shows the current state of the recovery log, including things like the number of log buffer pages, primary and secondary extent numbers etc which are configured via qm.ini/mqs.ini. |
|
| Back to top |
|
|
| umatharani |
| Posted: Sat Jan 24, 2015 4:41 am Post subject: |
|
|
Apprentice
Joined: 23 Oct 2008
Posts: 39
|
Hi,
If the number amqzlaa0 processes running is high with low number of connections, then I suspect the increase in number of amqzlaa0 processes could be because of the APAR IV46353 fixed in MQ 7.0.1.12. Please check the following URL for details on the APAR.
http://www-01.ibm.com/support/docview.wss?uid=swg1IV46353
Thanks,
mahesh |
|
| Back to top |
|
|
|
|
