| Author |
Message
|
| ThePostman |
 Posted: Mon Jan 21, 2008 8:10 am Post subject: MQ6.0 Accounting/statistics performance impact |
 |
|
Newbie
Joined: 21 Jan 2008
Posts: 6
|
Hello everybody,
We would like to enable the usage of statistics and accounting on queues of some of queue managers (in production - Solaris, AIX and Linux RH); but we have some doubts concerning impact on performances.
Does anyone of you have already evaluated the performance? What could be the impacts?
Goal of the project: cleaning no-more-used queues: there are more than 5000 old queues on some QM and we are sure that some are not used anymore (don't blame, I just arrive in the company and I'm discovering the existing awful mess  ). By enabling the queue accounting, it will assure us about queues that are still used (no, the applications using these queues are not running 24h/24, and looking IPPROCS/OPPROCS/QDEPTH is not a solution).
_________________________
J-F |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 21, 2008 8:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Not an answer to your question (because I don't have one), but an alternative if like most sites there's a pre-production environment:
Enable accounting and stats on the pre-prod queue manager. Run a regression test against this queue manager (using an existing pre-production test script if available). This will yield queues in use, or at least the common ones. Eliminate these queues from a list of all queues on the queue manager, yielding a list of "probably" not used. Use this list as input to a script & get/put disable all these "probably" not used queues. Run the regression test again to ensure common business functions still work, then run the script in prod.
For a period of time have a support procedure that for each "get disabled" or "put disabled" MQ error code they re-enable the queue & remove the queue name from the "probably not used" list. At the end of the period, delete all queues still on the list.
My 2 cents, offered as is and I hope someone does have the answer to your question. Personally I'd delete all 5000 queues, add them back as applications report 2085 errors while making the previous MQ admins write "I must keep proper records" in their own blood on the wall.
But I can be a little gung-ho in my methods. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ThePostman |
| Posted: Mon Jan 21, 2008 9:14 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2008
Posts: 6
|
I take note of your first tip (for the second, it isn't not possible to get blood of the last MQ admin because he was fired) but... of course, there is no existing regression scripts (after Chain Saw Massacre, the MQ Series Admin Massacre ). Moreover my client doesn't like the idea "change-property-and-wait-for-complaints" and prefers "it-works-then-do-not-change-anything". I would like to prove it that "monitor-queue-activity-during-some-weeks" is a good compromise, but if the impact on performance could cause a production issue, he will win... and I don't like to lose  )))
____________________
J-F
"A good queue is like a beer: actually empty and waiting to be fill" |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 21, 2008 5:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I believe this is really do to a failure to communicate.
The app folks should know which queues are being used.
If only by their JNDI names
The WAS Admin should know their JMS JNDI setup
All these folks need to talk to the MQ admin...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 22, 2008 12:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ThePostman wrote: |
| Moreover my client doesn't like the idea "change-property-and-wait-for-complaints" and prefers "it-works-then-do-not-change-anything". |
Ah - the "if we touch it the magic might go away" school of thought. My preferred advice for dealing with such clients involves trout (use the search button, it's a long story) but you might consider pointing out that while it works now, it's already hard to maintain and future development is only likely to increase your woes to a point where future development / maintenance / problem resolution becomes impossible. Does your client want to address the issue now, or when his back is to the wall?
I like the point fjb_saper made - queues in use should be able to be reverse engineered from JNDI (or other configuration files if you're using C or something). You could remove all the queues named in this configuration from a list of all queues, then employ my idea.
Including the blood. Even if he was fired someone must know where his last paycheck / pension statement / etc was sent. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ThePostman |
| Posted: Tue Jan 22, 2008 2:01 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2008
Posts: 6
|
Unfortunately, it is not so easy (I already made investigation): on more than 200 applications, there are only 34 JMS/J2EE applications (using JNDI). The rest of the applications are 50% of mainframe (I strictly have no view on it - SOX has limited my access and my knowledge of the mainframe world is very very very limited) and the rest are a mix of C, Java (stand-alone), .net applications.
Of course, we have already contacted some project managers to get information and we get reply for all most "recent" projects. But the story of the company is very complex (bank buying bank buying insurance being bought by a bank...); this explains why we don't have all details about the architecture. Very old applications are probably still used but nobody knows the technical background of them.
Then, by following your advices, I could easily remove 3000queues from my check-list ... and the problem stays the same: what will be the impact on the performance if we enable queue statistics/accounting properties on 2000queues?
_____________________________
J-F |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 22, 2008 4:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Accounting & Statistics should be reasonably impact free. Obviously you'll want to take some time to consider your settings carefully. But as far as I know, these are designed to be run in production and not have significant impact on performance.
Again, try it out first on one machine and see.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jan 22, 2008 4:17 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Postman, you in a tough spot ...
even if you turn on statistics and there is no performance degradation and you do find 3000 queues not being used for a week or so, how will you know for sure these aren't used by some quarterly or yearend process?
SOX has limited your access... that's only part of the story, SOX should give you the "management motivation" to map out each use and setup...
after all how are you going to motivate the deletion of the 3000 unused queues in a proper SOX "way" ?
If you need tools to visualise your mess to management, you know where to find me...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| rxm8778 |
| Posted: Tue Jan 22, 2008 7:34 am Post subject: |
|
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
| Isn't accounting and statistics only available on Z/OS? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 22, 2008 7:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| rxm8778 wrote: |
| Isn't accounting and statistics only available on Z/OS? |
What makes you say that?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rxm8778 |
| Posted: Tue Jan 22, 2008 7:54 am Post subject: |
|
|
Apprentice
Joined: 15 Sep 2005
Posts: 37
|
I am not sure where I got that from actually maybe a bad assumption of mine...(or could it be that it is how it was in 5.3)
Because in my mind accounting and statistics always related to SMF 115 and 116 records which is available only in Z/OS
But after reading this post I checked the MQ info center and I stand corrected:
| Quote: |
Accounting and statistics messages are generated intermittently by queue managers to record information about the MQI operations performed by WebSphere MQ applications, or to record information about the activities occurring in a WebSphere MQ system.
Accounting messages
Accounting messages are used to record information about the MQI operations performed by WebSphere MQ applications, see Accounting messages.
Statistics messages
Statistics messages are used to record information about the activities occurring in a WebSphere MQ system, see Statistics messages.
Accounting messages and statistics messages as described here are not available on WebSphere MQ for z/OS, however equivalent functionality is available through the System Management Facility (SMF), see the WebSphere MQ for z/OS System Setup Guide.
|
I had been assuming accounting and statistics was only available on Z/OS until today. |
|
| Back to top |
|
|
| ThePostman |
| Posted: Tue Jan 22, 2008 8:01 am Post subject: |
|
|
Newbie
Joined: 21 Jan 2008
Posts: 6
|
jefflowrey
I will try and I keep you informed. I agree that IBM should have installed this option with a minimum impact for production.
Michael Dag
We are sure that some applications are only running once a week (month/half-year/year...) but these applications have a "better" (operational point-of-view) SLA and this will give us "more" time to recreate the needed queue(s) from a backup. Other critical business could not lose one hour to resolve an issue (1st line support is often too slow to react at level of middleware  ).
With SOX, we can have limited access to the machine... limited means: "You have access to server xxxx from 01/02/2008 - 15h08 to 03/02/2008 - 15h07". To be SOX compliant, it is easy: as engineer, you have to write a procedure, to test it, to ask operational team to validate it and to schedule a change (that needs to be approved by the change management who will ask you more details and who will contact all business manager... ... ). I know: this SOXs
(for info: I know your tools because I have worked with it in the past - good job!)
rxm8778
Accounting/Statistics is available on distributed systems.
On Z/Os, you have to use SMF or a monitoring tool.
Good news: they found some CICS and IMS logs and this will help us to make a part of clean-up on the mainframe...
__________________
J-F |
|
| Back to top |
|
|
|
|
