| Author |
Message
|
| Ko |
 Posted: Wed Aug 05, 2009 1:47 am Post subject: Performance MQSeries 6.0.2.5 |
 |
|
Newbie
Joined: 05 Aug 2009
Posts: 9
|
Dear all,
we are using MQ Server 6.0.2.5 on Unix and we have an issue with the performance of MQSeries.
I see that many processes (grep on proces mqm) beginning with
/opt/mqm/bin/amqcrsta -m <QUEUEMANAGER>
Is it normal that there are more that one proces if the system is busy?
Is there also something like a tool to measure the performance?
Hope you can help us.
Best regards |
|
| Back to top |
|
 |
| WMBDEV1 |
| Posted: Wed Aug 05, 2009 1:50 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Check that the applications that are using client connections to talk to the QM are correctly closing their connections.
dis chstatus(channel) should show the connections on a particular channel, if you have more than you would expect its definatly time to look at the app  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 05, 2009 5:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| we have an issue with the performance of MQSeries |
What performance issue are you having with MQ? What symptoms are you experiencing? Can you be specific?
Is it just with client-connections, for example? Or does the same perf issue exist with client AND local connections?
What is new/changed on the server? Any new applications, for example?
What have you tried?
_________________
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 |
|
|
| bbburson |
| Posted: Wed Aug 05, 2009 5:59 am Post subject: Re: Performance MQSeries 6.0.2.5 |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Ko wrote: |
| /opt/mqm/bin/amqcrsta -m <QUEUEMANAGER> |
Those processes are associated with the inetd listener. Ever since version 5.3 IBM has recommended using the MQ listener instead. You'll still have multiple processes for client connections (amqrmppa I think they are called), but not as many and the ones that are there are more efficient in their use of system resources. |
|
| Back to top |
|
|
| Ko |
| Posted: Wed Aug 05, 2009 6:30 am Post subject: |
|
|
Newbie
Joined: 05 Aug 2009
Posts: 9
|
All, thanks for the answers!
When I do a top on the processes I see many commands beginning with:
/opt/mqm/bin/amqcrsta -m <QUEUEMANAGER>
When I do a dis chs(*) in MQSeries I see that there are many SYSTEM.DEF.SVRCONN channels (more than 60).
I am not really sure if it is a MQ problem but I see that our server(clustered) having some memory problems (and is swapping). When it is swapping I see as many as the described processes.
For my understanding, when I receive/send a message it will have a SYSTEM.DEF.SVRCONN channel and/or amqcrsta process? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 05, 2009 7:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| having some memory problems |
Swapping is normal behavior in any o/s. Swapping is not a performance problem unless you are missing SLAs. Swapping means that there is more demand for real storage (RAM) than is currently available.
The usual solution: add more RAM.
So, are you missing SLAs? Is anyone complaining? Other than many instances of the svrconn channel, what performance issues are you experiencing?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Aug 05, 2009 9:11 am Post subject: Re: Performance MQSeries 6.0.2.5 |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bbburson wrote: |
| Ko wrote: |
| /opt/mqm/bin/amqcrsta -m <QUEUEMANAGER> |
Those processes are associated with the inetd listener. Ever since version 5.3 IBM has recommended using the MQ listener instead. You'll still have multiple processes for client connections (amqrmppa I think they are called), but not as many and the ones that are there are more efficient in their use of system resources. |
Yes its amqrmppa and each one can handle 64 threads, or 64 channels.
Ko,
When IBM announced you should us runmqlsr and not inetd, performance was one of the reasons. Define a listener object for the QM using runmqsc and have the QM control its starting and stopping, and dump inetd for MQ.
This may or may not have anything to do with your perceived MQ performance problem.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Ko |
| Posted: Thu Aug 06, 2009 5:11 am Post subject: |
|
|
Newbie
Joined: 05 Aug 2009
Posts: 9
|
Hi,
we see on our server that the memory is increased to the max of 2GB RAM.
I see that the system reserves 25MB pro amqcrsta proces but only uses 3MB. Where is te rest of the 22MB? When we go to use a listener, does it mean that there will be more memory available?
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 06, 2009 5:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| we see on our server that the memory is increased to the max of 2GB RAM. |
Memory for what has increased to the max of 2GB? A queue manager instance?
_________________
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 |
|
|
| Ko |
| Posted: Thu Aug 06, 2009 5:29 am Post subject: |
|
|
Newbie
Joined: 05 Aug 2009
Posts: 9
|
| No I mean that we have only 2GB of RAM totally. Not pro instance. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 06, 2009 5:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Add more RAM. Refer to the Quick Beginnings manual to find the hardware requirements.
_________________
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 |
|
|
| JosephGramig |
| Posted: Thu Aug 06, 2009 8:02 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 06, 2009 8:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| JosephGramig wrote: |
| The inetd configuration is only supported for backwards compatibility. It is known to be the least efficient way to run channels. |
inetd became obsolete when runmqlsr came in years back.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Ko |
| Posted: Fri Aug 07, 2009 12:35 am Post subject: |
|
|
Newbie
Joined: 05 Aug 2009
Posts: 9
|
JosephGramig said,
The inetd configuration is only supported for backwards compatibility.
We use 6.0.2.5., on the other side they use 5.2, do you mean that this combination is not possible to run a listener? If no, do you need to define the listener on two sides (remote QM and local QM)? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Aug 07, 2009 2:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Ko wrote: |
JosephGramig said,
The inetd configuration is only supported for backwards compatibility.
We use 6.0.2.5., on the other side they use 5.2, do you mean that this combination is not possible to run a listener? If no, do you need to define the listener on two sides (remote QM and local QM)? |
No. For your queue manager, which is at V6.0.2.5, you should configure a Listener object, and place it under control of the queue manager. The other end must use the method appropriate to V5.2 on their platform - very brave people to still be on that version 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
