| Author |
Message
|
| obriencm |
 Posted: Thu Jun 03, 2004 2:41 am Post subject: contact admin/Contact Admin on Tandem NSK |
 |
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| I am having an issue where contact admin 3.5 running on a TANDEM system is killing the disks with I/O and also eating CPU time. Our Auto/Pilot group manager version is 4.1. Also another symptom of the issue is events are not being correctly published. Has anyone else experienced similar problems? or does anyone know of a solution. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Thu Jun 03, 2004 8:26 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Run measure and figure out which process is the culprit. Move that process to a dedicated cpu. If its the QS process, then you may have to define more qs processes.
What level of MQ??? Any CSD's/efixes???
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| obriencm |
| Posted: Fri Jun 04, 2004 12:10 am Post subject: more info |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Hi there,
MQSeries version is 2.2.0.1, PTF Level U473441, Efix Level IY24473. Over a 5 minute period there were over 3500 opens of MQSeries data files on one disk- the majority being on the files listed below :
O1EQROQC
OC2FOKNV
Q1EQROQC
TC2FOKNV
TTEEP00C
These opens/closes seem to be performed by the MQLQMAG processes on the same disk. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jun 04, 2004 4:52 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
"MQSeries version is 2.2.0.1"
---Hmm... You are way tooo outdated with the version. Other than no service, even the latest version 5.1 would be old when 5.3 comes out. You should seriously think of upgrading. If this is a production system, i cant imagine what an outage could do to your business, without support of any kind.
"These opens/closes seem to be performed by the MQLQMAG processes on the same disk"
---Was there only one lqma or multiple lqma processes. It is higly unlikely that only one opened the files so many times.
I would say you should then add more ec's and balance out over different cpus. Also use altmqfls to load balance the QS processes and even disks.
Hope this helps.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| obriencm |
| Posted: Fri Jun 04, 2004 5:26 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Thanks for your help. an upgrade is planned for MQSeries on the system, however the downtime needed for such is always a delaying factor. We also have begin moving the Q's to different disks as you suggest. The problem with these fixes is that all the do is mask the situation. We were hoping for a solution that would fix it once and for all.
Thanks again,
Conor. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jun 04, 2004 5:36 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
"The problem with these fixes is that all the do is mask the situation. We were hoping for a solution that would fix it once and for all.
"
---Load balancing processes, balancing queues onto different disk volumes is *NOT* a workaround, but it is a design consideration that should be adhered to before you actually implement even a single queue manager onto production. Hence all that i suggested are things that one must consider depending upon their requirements and needs.
As an aside, you may avoid the whole burden and time invested into this "resolving" process by upgrading to 5.1. One of the fixes removes the need for Q and O files for dynamic queues, which is what I believe contact admin is creating and using heavily. And that would reduce the disk I/o with more than 90% of what you are seeing now.
May be this is the solution you were looking for.
Good luck!!!
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Jun 10, 2004 12:38 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Thanks again for the advice. We are already in the planning phase for the upgrade to v5.1 of MQSeries on our Tandem systems.
In reference to the issue detailed above. I have checked the services that were running on the Group Manager server (running on W2K). I then stoped the following two as they do not need to be running for the functionality we are currently using:
AP-WMQ WORKGROUP MANAGER
AP-WMQ EVENT ADAPTER
Since stopping both of these services running on our Group Manager server, Tandem performance on both our Prod systems has returned to normal (i.e. the same as it was before our upgrade to AP4.1) also while it is still early days the Tandem now appears to be publishing correctly. We have now been monitoring both performance and event publishing throughout the last 2 days, and this appears to have "fixed" our issue.
Thanks again for all the help.
Conor. |
|
| Back to top |
|
|
|
|
