| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Mainframe Batch Application (BATCHSZ) |
« View previous topic :: View next topic » |
| Author |
Message
|
| hughson |
 Posted: Wed Nov 29, 2023 7:06 pm Post subject: |
 |
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
| RHeunes wrote: |
| I had a look at XBATCHSZ values they fluctuated a bit, but generally in and around 1,13 and 13,14 sometimes around 31,6 and 21,4. I am thinking of changing the BATCHSZ to 15 to see how it performs, Is it ok to make it 15? will it create more overhead for the MF? |
Reducing the BATCHSZ value on an MQ Sender channel will result in less messages per batch. This means that you will have more end-of-batch processing going on. So yes, this will create more overhead for both ends of the channel, as more frequent commit calls. However, reducing it to 15 based on the numbers you are seeing already doesn't look like it is going to change very much. Sometimes you get more than 15 in a batch and in those cases, you might now have 2 batches, so twice as many commits.
| RHeunes wrote: |
| Question, would setting it to 1 be a bad idea? I read that if you have network issues between two qmgrs, that it can be beneficial in such an instance. |
If you have a network issue then it might be worth looking into this. But you don't have a network issue, you have a CPU issue. So it doesn't seem like it would be relevant to your concerns. Also, making every single message be committed individually in its own batch is certainly going to increase overhead, and you sound like you want to decrease overhead.
You have told us your system is at 100%, but you haven't told us what is using all that CPU.
- If it is the CHIN address space, then fiddling with the BATCHSZ attribute to make the CHIN behave differently might be a useful exercise, although, it is rare for the CHIN address space to use so much CPU as it spends its life waiting on things, I/O or messages on queues. One reason for high CPU in the CHIN address space might be a looping channel exit.
- If it isn't the CHIN address space that is using all the CPU, then fiddling with configuration to tweak the behaviour of the CHIN address space is unlikely to have much of an effect on the overall 100% CPU usage of the system.
Is it possible that you can tell us what is using the majority of the CPU on this system? Why are you trying to improve things in MQ - is one of the MQ address spaces the culprit?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Dec 01, 2023 4:29 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9400
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Dec 05, 2023 3:21 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
CHIN performance & MQ CPU usage can be easily affected by
- Badly behaved Client apps (eg. CONN / OPEN / GET / CLOSE / DISC) for every message
- Accessing deep queues by msgid or correlid where the queue is not indexed (eg. a reply queue where there are a lot of old reply messages that were not ever picked up)
- Multiple connections continuously browsing deep queues
However, we await your sysprogs analysis of what is really going on in the LPAR.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
