| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| associating amzlaa0 process to client IP |
« View previous topic :: View next topic » |
| Author |
Message
|
| salem.muribi |
 Posted: Thu Sep 10, 2009 11:11 am Post subject: associating amzlaa0 process to client IP |
 |
|
Novice
Joined: 05 Sep 2008
Posts: 14
Location: Chicago
|
Anyone know how to tie these together? Was hoping there was a method on MQ 6 to figure out what application is pounding my queue manager.
dis chstatus gives me bytes sent/rcvd by IP's
dis conn, i can get a application name and tie it back to an IP
of course i'm working in linux x86_64 which has no admin GUI (could set up a 32 bit gui but still not sure it would show me what we are looking for)
Any ideas? |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Thu Sep 10, 2009 12:50 pm Post subject: Re: associating amzlaa0 process to client IP |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| salem.muribi wrote: |
| Anyone know how to tie these together? |
Why do you care about "associating amzlaa0 process to client IP"?
Run "top" it will show any high utilization.
Besides, 99% of the time, Java / J2EE applications will have an application name of "WebSphere MQ Client for Java".
I'm guessing that you don't have any security and all of your applications use a handle full of SVRCONN channels (very bad idea). First you should have implemented MQ security (SSL or exits) and secondly, each application should be using its own channel.
I have posted an open source project called: MQ Channel Monitor. It is written in Java so it will run on Linux just fine. It will display, in real-time, all important fields of all running channels (you can set a filter) of a queue manager. For more info, go to the following web page:
http://www.capitalware.biz/mqcm_overview.html
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| salem.muribi |
| Posted: Fri Sep 11, 2009 9:45 am Post subject: |
|
|
Novice
Joined: 05 Sep 2008
Posts: 14
Location: Chicago
|
Thanks Roger. And I was starting to think that either we were the only Linux x86_64 shop or that my issues were somehow always unique.
So "top" shows that one of the amzla00's was using 99 percent of one core. At this time, my probes showed a significant slowdown in API timings.
You are correct in that we have many clients using the same svrconn channel, but it would not be practically to create several hundred different channels here. I believe there are probably 500 - 600 clients at any given point in time.
What I am trying to do is find out which client is running is running up the cpu (possibly mq_getting with no wait).
Accounting statistics are enabled currently at the QM level. It would help to have this set at the queue level but once again, there are several hundred queues and the throughput on this QM is very high (all persistent) and I would be concerned about the additional overhead. We have actually overhwhlemed the linux I/O scheduler before resulting in a reboot.
Also we are not a java shop at all so i do get most of the app name using display conn.
I will give the utility a try and let you know.
Thanks!
Salem |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 11, 2009 9:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| salem.muribi wrote: |
| You are correct in that we have many clients using the same svrconn channel, but it would not be practically to create several hundred different channels here. I believe there are probably 500 - 600 clients at any given point in time. |
It's one MQSC script, built using a dead simple copy/paste or an almost as simple spreadsheet.
Even if you do not end up having a separate channel for each individual client, you should still create different channels for each different type of application, or remote site or remote server or etc.
You are leaving yourself wide open for a lot of security and management issues, of which this is but one, otherwise. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 11, 2009 11:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| salem.muribi wrote: |
What I am trying to do is find out which client is running is running up the cpu (possibly mq_getting with no wait).
|
As you do a channel status list, keep refreshing and watching the "messages" sent count for all your instances. If one is climbing rapidly, that could be your culprit. You should then be able to tie it to a specific IP.
"Messages" on a SVRCONN's Channel Status are MQ API calls, not actual application messages. An MQGET with no message found is 2 messages in that count. The MQGET request, and the MQGET result.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| salem.muribi |
| Posted: Fri Sep 11, 2009 12:09 pm Post subject: |
|
|
Novice
Joined: 05 Sep 2008
Posts: 14
Location: Chicago
|
Thanks Peter, i think that is exactly what i needed. Found an instance of the svrconn channel with 1.3 billion msgs. If these are indeed api calls as opposed to actual messages then this should be my culprit.
Guys i hear you on the security and provisioniong of these channels but i wasn't here from the beginning and trying to retrofit security for such a large and sensitive infrastructure isn't an easy task (30 or so production QM's). It is one mqsc script for me but dozens of configs for 2 or 3 dozen development teams.
Thanks for all your help.
Salem |
|
| 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
|
|
|
|
