ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportBATCHSZ?

Post new topicReply to topic Goto page 1, 2  Next
BATCHSZ? View previous topic :: View next topic
Author Message
csmith28
PostPosted: Tue Dec 13, 2005 12:01 pm Post subject: BATCHSZ? Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

Has anyone here taken the Advance WMQ Administration class recently?

When I took it the instructor gave us a mathmatical calculation dividing the value of BATCHES by the value BATCHSZ but I don't recall what result would make you want to modify the value of BATCHSZ.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Dec 13, 2005 12:04 pm Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Is this Channel batch size?
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
csmith28
PostPosted: Tue Dec 13, 2005 12:06 pm Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

yes.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Tue Dec 13, 2005 12:14 pm Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

I haven't taken the class, so I can't say what the instructor meant.

Channel Batch Size controls how many messages are kept in a unit of work.

If you have large messages flowing down a channel to a queue manager with a small log... you can adjust the batch size down to reduce the number of messages in the unit of work, and thus allow the messages to actually flow.

You could also decide to increase the batch size to reduce the amount of i/o that the QM does to it's log files.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
csmith28
PostPosted: Tue Dec 13, 2005 12:27 pm Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

Thanks Jeff but I knew that part, my question is.

OK say my BATCHSZ is 500 on my SDR Channel and BATCHES is at 41923. For the sake of argument we will assume the RCVR Channel is also set at 500.

So 41923/500=83.846 and all the messages are smaller than 4meg. I remember this much but I don't recall the signfigance of the result.

Does 83.846 mean I should?
a. lower the value of BATCHSZ
b. increase the value of BATCHSZ
c. leave it alone.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
wschutz
PostPosted: Tue Dec 13, 2005 5:30 pm Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

What could that possibly tell you? Batches is the number of complete batches since the channel started. That number goes up as time goes on.... MSGS must come into the equation ....
maybe ...

something = (batches * batchsz) / msgs

???
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
PeterPotkay
PostPosted: Tue Dec 13, 2005 5:42 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7493

Maybe you are thinking of this?
Quote:

One way of helping to determine whether there would be much advantage of BATCHINT is to look at the effective batch size. Issue a DISPLAY CHSTATUS and divide the number of messages by the number of batches. If this number is very low, (say between 1 and 2) then the channel is having to commit for each 1 or 2 messages which is inefficient and may benefit from BATCHINT. Note that this is only an indication since if all the messages are non-persistent BATCHINT won't help at all.

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
csmith28
PostPosted: Tue Dec 13, 2005 6:54 pm Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

PeterPotkay wrote:
Maybe you are thinking of this?
Quote:

One way of helping to determine whether there would be much advantage of BATCHINT is to look at the effective batch size. Issue a DISPLAY CHSTATUS and divide the number of messages by the number of batches. If this number is very low, (say between 1 and 2) then the channel is having to commit for each 1 or 2 messages which is inefficient and may benefit from BATCHINT. Note that this is only an indication since if all the messages are non-persistent BATCHINT won't help at all.


Um Peter, did you mean BATCHSZ instead of BATCHINT? Setting a BATCHINT would prevent the SDR from sending the commit signal to the RCVR when the XMITQ is empty.

Perhaps my memory is worse than I thought but you may have jogged it a bit. Assuming the SEQWRAP(999999999) has not been reached, if you divide the value of CURSEQNO by the value of BATCHES.

Thanks.

For example SDR channel BATCHSZ has been set to oh, 500.

dis chs shows the CURSEQNO is 4235033 and BATCHES is 55721. 4235033/55721 means that for every time the SDR Channel Batched on average 76 messages were sent. So the BATCHSZ is set unneccessarily high. But that's not a real problem unless there are vast fluctuations of message flow. The value of BATCHSZ could just as easily be 100.

Now, (stay with me) if the BATCHSZ were set to 50 on the same Channel the value of BATCHES would be much higher meaning that the result of the equation above with appropriate values would be more like 50 to 60 which would potentially mean that the value of BATCHSZ should be raised because the Sending MQManager could be slowing (however little) the availability of the messages on the destination Queue and BATCHing more often that is neccessary therefore increasing the load on the MQManager in Question.

I've never, ever fiddled with the BATCHINT attribute and I have only rarely found a need to modify the BATCHSZ attribute. But I think with the help of the responses in this thread I have found the answer I was looking for.

If anything I have posted in this response leads you to believe I have wondered off into the weeds, feel free to drag me back into the yard and slap me around.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Dec 13, 2005 7:07 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7493

I did mean batchint.

However, I look at it all this way. If the XMITQs is staying empty, maybe occasionally you see a blip of 1, and the CPU or I/O is not going bonkers, then these settings are fine.

If the XMITQ is backing up, and your BATCHINT is > 0, then possibly dropping it to 0 may help.

If the CPU and I/O is going nutz, indicating that the channels is committing for every 1 or 2 messages, maaaaaybe you want to up the BATCHINT (at the risk of delaying the availability of the messages on the receiving side).

If the XMITQ is backing up, regardless of what you do with BATCHINT, then maaaaybe it means the channels are spending more time committing than sending, in which case upping the BATCHSZ may help. I doubt it though unless the batch size was set to 1 or something. Left at the default of 50, I don't see how the over head of comitting every 50 messages would be noticed.

Dont use batches and Seq # for your math. You can't trust the seq # for this purpose. Use # of messages and # of batches, as described above. What does that give you for an effectibe batch size? My effective batches are always between 1 and 3 (BATCHINT - 0 BATCHSZ = 50), and I am fine with that. I am not going to up my BATCHINT to boost that # and delay messages as a result. I don't care how often the channel commits - The XMITQ is staying at 0!
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
csmith28
PostPosted: Tue Dec 13, 2005 9:40 pm Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

Peter, Thank you but.

Like I said I've never fiddled with BATCHINT so this is not an issue. So for the sake of argument let just assume the value of BATCHINT is 0.

The point is, today someone asked me when one should consider altering the default value of BATCHSZ to something other than 50 to improve SDR Channel performance and over a year ago while attending the IBM/UX Advanced WMQ Administration class the intructor mentioned an equation that under certain circumstances would be valuable to evaluate whether or not the default of BATCHSZ(50) should be altered.

Under these circumstance, while taking into consideration that the value of CURSEQNO and BATCHES are always changing but they can show a trend.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Dec 14, 2005 2:35 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Quote:
Under these circumstance, while taking into consideration that the value of CURSEQNO and BATCHES are always changing but they can show a trend.
As Peter said, you should use MSGS, not CURSEQNO. The attributes BATCHES and MSGS are both reset to 0 when the channel is started, CURSEQNO is not.
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
Mr Butcher
PostPosted: Wed Dec 14, 2005 2:59 am Post subject: Reply with quote

Padawan

Joined: 23 May 2005
Posts: 1716

msgs / batches from the channel status will show on average how bvig the "real" batchsize is.

Anyway, the settings fo batchsz and batchint is just a consideration between message speed abd cpu usage. The higher the message speed, the higher the cpu usage (in this case message speed means availability at the remote end for a getting application).

Highest speed - batchint 0 batchsz 1 - but every message is committed

High speed - batchint 0 batchsz xxx - which means if there is a (little) message queueing on the xmitq xxx messages are transfered (committed) in one go. this will save some commits and so some cpu. if there is no queueing on the xmit when using batchsz 0 then this setting has no effekt (except on errors where messages pile up and similiar).

next is batchint yyy batchsz xxx - now the mca waits the time specified in batchint before commiting the batch (if it is not fuill), this again will save some cpu but will slow down message availablity at the remote end because of the wait, and it really depends on the application design and the batchint and batchsz settings how "big" that delay is (or how big it can be)

i wrote that in a different thread some time ago, but again here in a short version: a batchint of 0,15 seconds which raised the average batchsz of the channel saved my 10% of the CHIN cpu usage.
but i also have mq systems where i am not allowed to use any batchint to make messages as fast as possible.
_________________
Regards, Butcher
Back to top
View user's profile Send private message
csmith28
PostPosted: Wed Dec 14, 2005 6:34 am Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

wschutz wrote:
Quote:
Under these circumstance, while taking into consideration that the value of CURSEQNO and BATCHES are always changing but they can show a trend.
As Peter said, you should use MSGS, not CURSEQNO. The attributes BATCHES and MSGS are both reset to 0 when the channel is started, CURSEQNO is not.


Really from the Command reference:
Quote:
Use RESET CHANNEL to reset the message sequence number for a WebSphere
MQ channel with, optionally, a specified sequence number to be used the next time
that the channel is started.

_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
wschutz
PostPosted: Wed Dec 14, 2005 7:00 am Post subject: Reply with quote

Jedi Knight

Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)

Sorry, I don't understand what point you're making...
_________________
-wayne
Back to top
View user's profile Send private message Send e-mail AIM Address
csmith28
PostPosted: Wed Dec 14, 2005 7:19 am Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1197
Location: Arizona

Nevermind, I was thinking of something else. I shouldn't read this board before my coffee starts taking affect.



So, assuming you have stopped the channel reseting the value of BATCHES to 0, then reset the channel so that CURSEQNO is 1. Also assume that value DISCINT is 0 or the channel will remain running for the duration of your test.

Once you start the Channel and have waited for a certain period of time you can divide the value of CURSEQNO by the value of BATCHES to see an average of how many messages the Channel is handling per batch.

So for the sake of argument if the Channels BATCHSZ is 50 and the result of that equation is say 10. It means that the Channel is on average, batching once for every 10 messages sent so there is no real reason to alter BATCHSZ unless you are having system resource issues.

But if the result is say 50 or 49 depending on your particular you may want to consider raising BATCHSZ to increase through put and reduce overhead on the MQManager.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportBATCHSZ?
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.