|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Performence Issue With MQSI & MQ Series |
« View previous topic :: View next topic » |
Author |
Message
|
abiram8 |
Posted: Tue Jul 02, 2002 12:06 am Post subject: Performence Issue With MQSI & MQ Series |
|
|
 Master
Joined: 27 Mar 2002 Posts: 207 Location: India
|
Hi,
Application Details : MQ Series5.2,MQSI2.1 For Windows NT4.0
We are using the MQ server for our application Development , where Our "N" applications communicate with the MQ Server & MQSI (V2.1) for getting the information required using Publish-subscribe Methdology
We face a serious issue of QueueManager Connection some times it is slow but once restart the MQ Server + MQSI the performence is fast for 5 months and then degrades its performence.
But once the application goes live we cant restart our MQ Server to get better performence
any one have faced this similar problem please let me know the permenent solution
Note: 1) No other Application is involved with the MQ Server it is the seperate Server maintained
2) Iam not sure but it cant be network issues since it works fine for 5-6 months from the day of restart
Thanks
R.Abiram |
|
Back to top |
|
 |
CodeCraft |
Posted: Tue Jul 02, 2002 3:38 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001 Posts: 195
|
Fast for five months? Better than most of us hoped for!!! Is this what you meant to say?
I would expect on *any* system there can be processes which leak and deteriorate. This would need careful analysis, since even if WMQI itself was not at fault, it could begin to show poor performance due to memory/disk fragmentation, and, if there is another leaking process, because the memory manager will eventually be forced to start thrasing on it's paging files.
However, since restart of MQServer and WMQI seems to resolve the problem, you could check for leakage in WMQI (I don't support MQ!). Check your DataFlowEngine processes and see does their memory usage increase over time?
What CSD is applied to WMQI?
What's the availability of the application supposed to be like: If it's supposed to be 24x7, are you considering a failover scenario. If so, you could use a manual triggering of your fail over to solve this particular problem.
If not, you could look at having a pair of brokers and using clustering so that they can both feed of a single input queue: You could then alternative restart the brokers.
If this has to be a guaranteed 24x7 situation, you will need failover, and I think you can solve this problem in that context. |
|
Back to top |
|
 |
abiram8 |
Posted: Wed Jul 03, 2002 4:19 am Post subject: |
|
|
 Master
Joined: 27 Mar 2002 Posts: 207 Location: India
|
Hi CodeCraft
What's the availability of the application supposed to be like: If it's supposed to be 24x7
What do you mean by 24x7 can you brief on that
R.Abiram |
|
Back to top |
|
 |
CodeCraft |
Posted: Wed Jul 03, 2002 4:22 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001 Posts: 195
|
24 hours a day, 7 days a week, eg: Always on. |
|
Back to top |
|
 |
mpuetz |
Posted: Fri Jul 05, 2002 2:25 pm Post subject: |
|
|
Centurion
Joined: 05 Jul 2001 Posts: 149 Location: IBM/Central WebSphere Services
|
Hi,
from the amount of information you posted it is impossible to
deduce what could cause this. A 'typical' cause would be clogging
of your queues with old messages. I.e. if your queues fill up slightly
over time, performance will go down significantly. Remember,
only an empty queue is a good queue !
If that is the case you should think of way how you get rid of
those long term survivers. _________________ Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
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
|
|
|
|