| Author |
Message
|
| mqnomad |
 Posted: Tue Apr 20, 2010 9:23 am Post subject: Performance help Tuning queue buffers and other issues |
 |
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
What has been the general experience
The queue manager in question handles mission critical processing for a major US corporation.
According to information gathered, messages are non-persistent.
A new environment is being defined. Part of the adjustments is changing the logging parameters .
Q1 - If the messages are non-persistent, what difference will doing all the logging related changes make?
Another change being done is increasing the DefaultQBufferSize and the DefaultPQBufferSize. It is very clearly documented on the Perf. Eval pack for Linux that sometimes increasing these buffers will exhaust real memory and hurt performance.
Q2 - has anyone had any experience making changes to these queue buffers? (I know there are a lot of details on msg. sizes etc. I'm leaving out).
Q3 - is there an MQ V6 equivalent to support pack MP01 on tuning queue limits? Have the internals changed enough on V6 that changing these queue buffers should not even be tried (particularly in prod. without testing?) ... yes I know ... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Apr 20, 2010 9:48 am Post subject: Re: Performance help Tuning queue buffers and other issues |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqnomad wrote: |
| Q1 - If the messages are non-persistent, what difference will doing all the logging related changes make? |
Very little.
| mqnomad wrote: |
| Q2 - has anyone had any experience making changes to these queue buffers? (I know there are a lot of details on msg. sizes etc. I'm leaving out). |
The need has never arisen in my WMQ career to date
| mqnomad wrote: |
| Q3 - is there an MQ V6 equivalent to support pack MP01 on tuning queue limits? Have the internals changed enough on V6 that changing these queue buffers should not even be tried (particularly in prod. without testing?) ... yes I know ... |
I'm not aware of one, and have nothing to add you don't already clearly know...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Apr 20, 2010 10:33 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
MsgId, CorrelId, GroupId, are 24 byte fields. They do not contain anything but 24 bytes.
These are bytes only, and should not be treated as a String or hex or anything else.
They are not subject to conversion. Thus, a msgid in the request message sent from Win to z/OS (or any other config of platforms) will arrive exacly as sent - 24 bytes. The replying app need only copy the inbound msgid to the outbound correlid field and put the reply msg to the reply-to-queue.
At the requesting app, the inbound reply msg correlid will exactly match the outbound request message. |
bruce,
Are you having one of my doh! moments?  I think you answered a different question to the one here 
_________________
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 |
|
|
| Vitor |
| Posted: Tue Apr 20, 2010 11:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
It might be an answer to this. Or it might not.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 20, 2010 12:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes. Well, it is/was more of a 'wrong post' reply moment. I often compose replies in Notepad or something, then copy into a reply.
I guess I copied into the wrong post. Not so much a doh! moment, as a 'duh' moment. Similar, yet different.
_________________
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: Tue Apr 20, 2010 1:53 pm Post subject: Re: Performance help Tuning queue buffers and other issues |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| mqnomad wrote: |
| Q2 - has anyone had any experience making changes to these queue buffers? (I know there are a lot of details on msg. sizes etc. I'm leaving out). |
The need has never arisen in my WMQ career to date
|
mqnomad,
Most people that ask about this seem to be people with a solution looking for a problem to solve. Not that there aren't legitimate cases where this is needed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqnomad |
| Posted: Tue Apr 20, 2010 2:20 pm Post subject: |
|
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
no, I wish I was selling a solution .... well, maybe not, these are competetive times.
the client wants to make these changes, move the box straight to production, and receive reassurances (from me) that these changes will solve their problems.
I just chatted w/a couple of people who have actually used these - but without any docs with some tested cases I feel I'm working in the dark. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 20, 2010 2:24 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| the client wants to make these changes, ...these changes will solve their problems. |
What problem?
_________________
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 |
|
|
| Vitor |
| Posted: Tue Apr 20, 2010 6:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqnomad wrote: |
| the client wants to make these changes, move the box straight to production, and receive reassurances (from me) that these changes will solve their problems. |
It's not an assurance I'd be happy giving. As I said, I've never changed these values in a little over 13 years of running WMQ professionally. I'd be very surprised if these "problems" didn't have a different root cause. Especially if these "problems" were connected to throughput.
| mqnomad wrote: |
| I just chatted w/a couple of people who have actually used these - but without any docs with some tested cases I feel I'm working in the dark. |
What people? It's very unusual in my experience to change these values. Why do they not have tested cases? Why are your clients so gung ho about going straight to production with your assurance? Why not allow you to test this rather questionable solution?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Apr 21, 2010 2:51 pm Post subject: Re: Performance help Tuning queue buffers and other issues |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqnomad wrote: |
| Q1 - If the messages are non-persistent, what difference will doing all the logging related changes make? |
You didn't say what logging parameters are being changed. But the answer to your question is almost certainly "None".
| Quote: |
| Q2 - has anyone had any experience making changes to these queue buffers? (I know there are a lot of details on msg. sizes etc. I'm leaving out). |
Maybe if a few of the details were shared we would be able to comment more.
For many years now people have used these tuning parameters. They are mentioned in the performance reports (last time I looked, anyway). They are there to be used if needed (and subject to the caveats you have noted). But your client needs to think again about their attitude to testing. You don't just throw a change into production without doing dry runs and representative tests on a test system.
| Quote: |
| Q3 - is there an MQ V6 equivalent to support pack MP01 on tuning queue limits? Have the internals changed enough on V6 that changing these queue buffers should not even be tried (particularly in prod. without testing?) ... yes I know ... |
Nothing should be tried in prod without testing. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 22, 2010 1:22 am Post subject: Re: Performance help Tuning queue buffers and other issues |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mvic wrote: |
| Nothing should be tried in prod without testing. |
While I agree with this, let's step back a minute.
The consideration here is not altering a running production environment, but configuring a new environment with different parameters. While normally one doesn't like to do this, certain things are perfectly acceptable. Like the maximum number of log pages - assuming the number is known to be well within the hardware capabilities of the new system. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 5:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
All true for tuning generally. But, we don't tune whimsically or in a vacuum.
Setting log parameters, for example, should be based on predicted use (number of messages x message size, availability of sufficient RAM, sufficient I/O, etc..
Pre- and post-change activity should include measurements to validate that the change did, in fact, meet expectations (improved whatever needed improvement).
I would not guarantee or assure a cleint that fiddling with this or that will achieve a desired result unless 1) the desired outcome is quantifiable; 2) the desired outcome is demonstrable (provable); 3) the desired outcome did not adversely affect overall operation of the box, the qmgr, other qmgrs, other applications,.
Dedicating more RAM to one function, for example, takes it away from another.
_________________
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 |
|
|
| mvic |
| Posted: Thu Apr 22, 2010 5:39 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| Dedicating more RAM to one function, for example, takes it away from another. |
True, except when it is free RAM not in use by anything else.
Everything else I agree with. |
|
| Back to top |
|
|
|
|
