| Author |
Message
|
| bobbee |
 Posted: Tue Mar 03, 2020 9:58 am Post subject: amqrmppa to Queue Connection |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| If I have an amqrmppa, How do I tie this to the open connections on the queues |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Mar 03, 2020 10:47 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Are you saying that DIS CONN(*) doesn't work for you ? DIS CONN(*) TYPE(ALL) should show you each connection id and follow that by the handles that it has open. A little awkward to use if you have just RUNMQSC but if you have MQSCX or MO71 then you can filter or sort the data to make it easier.
Or have I misunderstood the question ?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Mar 03, 2020 11:31 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| L3 received core files and they show one connection with alot of memory. So I have a PID on the amqrmppa that has the excessive memory allocated. I wanted to trace this back to the Queue it is connected to, or the IP, maybe. So the customer can figure out the application. Trying to trace back. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Mar 03, 2020 11:40 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Ok well that's a little more awkward I would say. An AMQRMPPA process is a generic channel pool process. So, you could have up to 100 channels running in there. Of all types from all different IP addresses. If you could somehow find the Connection Id then again you could use DIS CONN(*) to tell you the channel/IP address that was using that connection. Have you checked for FDCs ? There should be enough info in there to tell you the active channel.
Of course it is not that unusual for an AMQRMPPA process to use a fair amount of memory. If you have a lot of channels, each moving large messages then it will mount up.
If the problem is recreatable then you can configure your channel pool processes to accept less channels - even make it one channel per process. The viability of this would depend on how many channels instances you have running though and whether this is a production system etc.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Mar 03, 2020 12:09 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| Thanks P, I was afraid you would say that. In fact the have every Tom Dick and Harry coming in on ONE channel. Thanks for that additional info. Will look into that. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Mar 03, 2020 1:18 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
There are cryptic ways to tie the amqrmppa pid/tid back to the remote port on the client side. However, it involves using amqrdbgm and native tools (like lsof on Linux) to track this down. Somewhere on the mqseries.net I documented how to do it, so you could search for the details if interested.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Mar 03, 2020 1:55 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 04, 2020 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
As mentioned another favorite is dis conn(*). However I would strongly suggest you use a qualifier (objname) like the queue name (remote queues work with this) to ferret out more specific information. That is if you/ or the customer/ have an idea which queues are impacted. This can allow you to trace back to the connection, the host, the channel, the application...
Hope it helps 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Mar 04, 2020 7:26 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| So in this case there is amqrmppa processes that are consuming large amounts of memory. The constantly incrrease. We can see the offending amqrmppa process and it's pid. We need to start from that point.If we see the queue attached we can figure out the app. High volume QMGR, many apps. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Mar 04, 2020 8:09 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Mar 04, 2020 8:56 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
| Code: |
I notice only one amqrmppa process grew to an enormous size (7 GB
VSZ reported in ps -efl).
These are the last few in the list of 121, sorted according to VSZ.
0 S mqm 27743 26043 0 80 0 - 431513 poll_s Mar01 ? 00:03:04 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 1678 26043 0 80 0 - 438571 poll_s Mar01 ? 00:09:34 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 17391 26043 3 80 0 - 439646 poll_s Mar01 ? 00:43:47 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 29490 26043 0 80 0 - 483470 poll_s Mar01 ? 00:18:16 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 17688 26043 0 80 0 - 1445062 poll_s Mar01 ? 00:10:21 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 16122 26043 3 80 0 - 1578865 poll_s Mar01 ? 00:50:10 /opt/mqm/bin/amqrmppa -m HAQ1
0 S mqm 16282 26043 3 80 0 - 7809350 poll_s Mar01 ? 00:41:57 /opt/mqm/bin/amqrmppa -m HAQ1
A small number of others are in the 1-2 GB range - not normally a
concern. The rest are approx 400 KB - no concern at all.
So I am trying to guess at why this particular process got so big, and
so much more than the others. So far, no plausible idea occurs to me,
but I will say this in my update in case someone else reading this has
an idea.
|
|
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Mar 04, 2020 9:06 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
we would like to tie that pid back to the Queue or IP.
Think I mentions this, there is an API log that shows many transactions with 4-8 MQGETS over a LUW of 6-10 hours in duration. Crazy |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 04, 2020 9:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
Any meaningful definition of “transaction” includes some reference to “short lived”.
_________________
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: Wed Mar 04, 2020 10:51 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
It is not clear to me what is the exact issue you are trying to investigate, but just a note that virtual memory (VSZ) usage of a process is somewhat irrelevant, unless you are hitting some type of process address space limit (like a 32 bit process can have 2 Gb of virtual memory in general). If this is a 64-bit process, then virtual memory usage is usually irrelevant. RSS (physical memory) usage is usually the concern.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Mar 04, 2020 11:24 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 546
Location: Tampa
|
my issue in the post here is, given a pid ,referencing an amqrmppa process, how do you trace that to a connection and or the queues opened.
there are thousand of connections an many applications. Trying to figure out the one owning this connection.
I was asked to supply some informatio. Lets not get side tracked by the information from the case. AI was asked a question on the PIDs |
|
| Back to top |
|
|
|
|
