| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MaxUncommitedMsgs Parm - Best Practices |
« View previous topic :: View next topic » |
| Author |
Message
|
| wschutz |
 Posted: Thu Oct 06, 2005 3:38 am Post subject: |
 |
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
IMHO, if it's not broke, don't try to fix it ....
Unless you know that you have applications that exceed this limit and will get MQRC_SYNCPOINT_LIMIT_REACHED, then I think you should leave it at the default value. 10,000 uncommitted messages seems like a lot to me.... but I suspect most shop's leave this attrbute at the default value 
_________________
-wayne |
|
| Back to top |
|
 |
| hopsala |
| Posted: Thu Oct 06, 2005 5:13 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Well, generally speaking, the WMQ default values make no since at all, and the maxuncommitmsg is no exception; so don't go about bringing logic into it 
Specifically, I take this parameter as a logging-scheme parm - I use it to prevent applications from crashing mq since the (circular) log has wrapped around itself with an open transaction or the (linear) primary+secondary log pool filled up. To keep appls at bay, I calculate how much space = 10000 msgs, compare with primary log pool, and make sure there's no way of open syncpoints getting out of hand.
To counter wayne on this one, IMHO it is vital to change almost all WMQ default values (queue & channel properties, maxuncommitmsg, triggerint etc) if you don't want something to become broken at some point in the future  |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 06, 2005 6:24 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Allow me two petite points, if I may:
1. Please change the topic of this thread, it's slightly misleading - should read something in the line of "MaxUncommitedMsgs parm - best practice".
2. How is it that you work with such huge batches? Usually above the 20 msgs-per-commit line there's no worthwhile additional benefit. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 06, 2005 9:27 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| asif wrote: |
| Quote: |
| 2. How is it that you work with such huge batches? Usually above the 20 msgs-per-commit line there's no worthwhile additional benefit. |
I'm still trying to find the answer to that question from our developers. That said, I would like to know your openion on you second question above that there is no additional benefit? |
Well, i've just gone over almost every "performance evaluation" and "capacity planning" support pac there is, but apparently they had simply taken out the relevant section - it was there is v5.2 SPs, I swear it!
Fortunately (?) I am an IBM instructor, so I have here the course text for MQ30 - "Advances System Administration for Distributed Platforms" (v5.3), and there's a graph here, showing a performance increase of 100% between BATCHSZ(1) and BATCHSZ(2), an increase of 200% between (1) and (5), and only an increase of 300% between (1) and (20), and the graph flattens after that (can you say, "a finite supermum"?)
These are not exact figures, and i'm afraid I can't send or paste sections from the courses (copyright etc etc), but it has been my experience during batch tests in 5.2 that this is correct. Keeping in mind that the greater the batch, the heavier the MQBACK (automatic or driven), it's worthwhile keeping this parameter value as small as possible.
I guess you could just try it out, there are all sorts of readymade benchmarking tools out there, and in v6 I think there's one built in, so it should be simple enough. Anyhow, keep us posted. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 06, 2005 2:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What happens when you have a trigger every app that gets more than 10000 messages in a very short time (file load). They would bust the 10,000 max uncommitted limit as well. This is one reason we had to up ours.
Note this is not normal behavior of the app. Only catch up after some problem and down period.
Thanks  |
|
| 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
|
|
|
|
