Jim,
When you sit down the SAN people ask them to run a little test with
you. Suggest to them a schedule of when they will run these replications
over the next week or two. During that time be sure to collect and maintain
the application audit logs. After the test period you should be able to use
the audit logs of the applications to show that at no other time does this
problem occur. It sounds like that during these 'pauses' there is no disk
i/o going on at all. If there are applications other than MQ related apps,
see if you can get some information showing these 'pauses' are also
affecting them.
Don Thomas
EDS - PASC
* Phone: +01-412-893-1659
Fax: 412-893-1844
* mailto:[EMAIL PROTECTED]
-----Original Message-----
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 2:34 PM
To: [EMAIL PROTECTED]
Subject: MQ "Problem" - Advice Needed
We have periodic "pauses" on some of our Solaris servers. CPU usage drops
down to nothing for a couple of minutes, then things begin to function
normally again. Many of our MQ apps on Solaris were written in the last two
years, and maintain exhaustive audit trails, Those audit trails showed that
their applications were waiting on an MQPUT for the entire time. Everything
on the machine pauses, by the way, but it's these MQ apps that keep the
audit trail.
So I did some investigation, and eventually discovered that the pauses
seemed to coincide with something our storage administrator was running. It
is a series of commands - issued on the mainframe - which causes our SAN to
replicate to our hotsite. I ran the Unix iostat command during the pauses,
and sure enough, the disk service times had gone way up, then back to a
couple milliseconds after.
So I told the storage team about it (2 months ago!). They claim not to see
any problems, and have now decided that it's an MQ problem. They want to
meet with me, and have me "explain what the MQPUT command is, and how it
works."
It seems pretty obvious that they don't intend to work on this, and are in
the process of putting up a stonewall by shooting the messenger. It's much
like dealing with a difficult vendor, except the fact that we work for the
same company in some ways makes it even more difficult. I'd be tempted to
raise hell with a vendor, but that could be a career limiting move in this
case.
So... I'm interested if anyone has seen a similar problem. And I'm also
interested in any advice on how to get the SAN team to do the right thing
and take ownership of the problem.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
