| Author |
Message
|
| PeterPotkay |
 Posted: Wed Oct 23, 2002 9:50 am Post subject: How does MQSI handle an MQ message inside? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Assume this flow:
Input Node ----> Compute Node1 --------> Compute Node2 ---------> OutPut Node
If I put 10 messages on a queue, the Input Node picks up Message #1 and assuming all is good sends it out it's Output terminal to Compute Node1.
If Compute Node1 successfully accepts Message #1, does the Input Node go to get Message #2 even before Compute Node1 is done handling Message #1?
If yes, what happens to Message#2 if the Input Node sends it out it's Output Terminal before Compute Node1 is done processing Message#1?
I guess the big question is, In a flow, if a preceding node is done handling a message, but the following node is still busy with a prior message, what happens to the message in the preceding node if it ready to leave that node? Are these message being held in memory?
Or do the nodes all "talk" to each other to know when they are ready to accept another message, in which case I would think sooner or later you would see the original MQ queue backing up?
I have this question because no matter how fast we throw messages at MQSI, the Input queue never seems to back up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| kirani |
| Posted: Wed Oct 23, 2002 7:31 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Peter,
By default a message flow runs in single thread mode, this means next message will not be processed (or picked up from the input queue) until current UOW reaches some logical end. You can configure your message flow to use more than one thread by increasing number of additional instances while deploying, you could also do this by deploying your message flow to more than one execution groups.
Your queue will build-up if an application which is feeding WMQI is faster than Message Flow processing.
I hope this answers your question. 
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Oct 24, 2002 3:29 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Hi Kiran,
I work with Peter and it's my flow he is asking about. So if they put a 1000 messages on the request queue( a remote queue def that points to the input queue to the WMQI input queue) and we don't see a queue depth on the input queue to the WMQI messageflow backup can we assume that our messageflow is not the bottleneck? What we see is the box's memory goes way up and cpu spikes and transmit queues tend to backup.
Karen |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 24, 2002 3:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Our MQSI is on our HUB, while applications that put messages that need MQSI reside on the spokes, and use remote queue defs to get there messages to MQSI. No matter how fast those apps put their messages, the MQSI local input queue never backs up, but what we do see is that the transmit queues on the spokes going to the hub start to back up for ALL traffic (MQSI bound or not) during our stress test.
We have determined thru discussions on the listserve that the MCA's are lower on the totem pole for memory allocation than MQSI. In other words, when MQSI has all it can handle, the MCAs have to wait for processing power, and as such cannot communicate with the spoke MCAs, hence those XMIT queues start backing up.
The test we will run today is to use an app local to the MQSI Input queue to put messages as fast as possible. Based on what you have said in the above post, I would then expect the Input queue to start showing some depth, correct?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Oct 24, 2002 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Karen,
If you don't see any messages backup on input queue then your Message Flow is not a bottleneck. In one of my testing i found that the application which puts messages on local queue was slower than my message flow. If you deployed your message flow to only 1 EG only and if you don't have any major processing running on Broker box, you should see one of the Dataflowengine process using 100% CPU.
| PeterPotkay wrote: |
The test we will run today is to use an app local to the MQSI Input queue to put messages as fast as possible. Based on what you have said in the above post, I would then expect the Input queue to start showing some depth, correct?
|
Only if MQSI processing is slower than MQPUT application.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Tibor |
| Posted: Thu Oct 24, 2002 8:02 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| kirani wrote: |
| ...If you deployed your message flow to only 1 EG only and if you don't have any major processing running on Broker box, you should see one of the Dataflowengine process using 100% CPU... |
Not sure, if you have more thane 1 CPU, because DFE is multithreaded, so peak should be under 100%. On AIX (2 CPU) this is so 75%.
Peter:
Can you can isolate your tasks by CPU? (it's dependent by OS)
Tibor |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 24, 2002 11:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| Quote: |
If you don't see any messages backup on input queue then your Message Flow is not a bottleneck.
|
Well, if the putting application is on a remote queue manager, MQSI can be the bottleneck and the input queue can be zero. In this scenario, if the putting app is putting the messages faster than MQSI can handle them, MQSI uses all the memory on its box, and thus the MCAs are left with out memory. Now the XMIT queue to the MQSI box starts to back up.
Rerun the same test with the MQSI flow turned off, and the XMIT queue never backs up, but the Input queue rises very quickly.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Oct 24, 2002 4:17 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Well, it depends on how many EG's you have created and how many CPU's do you have on your box. Let's say if I have a 4 CPU box and I create only 3 EG's, thus EG's will use 1 CPU each and one CPU could be used for processes such as Databases, MCA's etc...
Could you please tell explain the configuration of your box?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| lung |
| Posted: Thu Oct 24, 2002 10:20 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
| Quote: |
| Well, it depends on how many EG's you have created and how many CPU's do you have on your box. Let's say if I have a 4 CPU box and I create only 3 EG's, thus EG's will use 1 CPU each and one CPU could be used for processes such as Databases, MCA's etc... |
Kiran, does this mean that if I have a 4 CPU box, and this box is only used for my broker, and in my broker i only have 1 EG, i will under-utilise my broker? (1 eg uses only 1 cpu, which means 3 cpu will go unused?)
So in order to optimise performance, i should duplicate my 1 EG into 4 EGs in total?
I thought Execution Groups is just to categorise the flows and have no impact/effect on performance... Looks like I'm dead wrong haha
_________________
lung |
|
| Back to top |
|
|
| kwelch |
| Posted: Fri Oct 25, 2002 5:05 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Kiran,
Our production box only has 1 processor. There are 9 execution groups in the broker. Each execution group has a number of flows. Some have as many as 14 messageflows in them. We know that our box was under configured. It has 1 gig of memory but only 600 mhz.
Each executioin group is a process? Each messageflow in the execution group has a processing thread? Does the memory get divided up by execution group? Or do they get as much as they can when they need it?
Karen |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Oct 27, 2002 11:05 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Karen,
Because of your hardware configuration MQSI is slow on your box.
Yes, EG is an OS process and Messages flows are processing threads within that process. I don't think the memory gets divided for each EG. But when the complete memory is used other threads will have to wait for resources.
Lung,
Yes you are under utilizing your broker. 1 EG uses only 1 CPU at a time. Create 3 more EG's on your broker box and deploy your message flows to these EG's evenly.
You will get optimal performance if you follow this
| Quote: |
Number of EG's (in Total) = Number of CPU's.
|
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| lung |
| Posted: Sun Oct 27, 2002 4:59 pm Post subject: |
|
|
Master
Joined: 27 Aug 2002
Posts: 291
Location: Malaysia
|
Thanks, Kiran!
Now let's assume I have two message flows, MF-A and MF-B. I put both these message flows in execution group EG-1.
So does this mean that the two message flows in EG-1 will share 1 CPU only? So, in order to optimise performance, should I just duplicate EG-1 (into EG-2) or should I just remove MF-B from EG-1 and put it into another execution group (EG-2)?
Thanks!
_________________
lung |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Oct 27, 2002 6:21 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Lung,
Yes, if you put both the message flows in 1 EG, they will share 1 CPU only.
After you create another EG (EG2), you could have following configurations:
1. EG1 - MF-A & EG2 - MF-B : In this case only one instance of MF-A and MF-B is running. Both the message flows will use 2 different CPU's.
2. EG1 - MF-A, MF-B & EG2 - MF-A, MF-B: In this case there are 2 instances of each message flow running on 2 different CPU's. In some cases you don't want to run your message flow in multiple instances mode because of message ordering.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Tibor |
| Posted: Sun Oct 27, 2002 11:36 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| kirani wrote: |
| Yes, if you put both the message flows in 1 EG, they will share 1 CPU only. |
Disagree. I'm working on AIX with only one EG with a lot of msgflows. When broker ran on a single CPU environment, the DFE consumed 100%. But now there is a 2-way SMP configuration and same DFE process is using on both CPU (max 75%). I have no official measure, just a "look-and-feel" 
But this is maybe a platform dependent behavior (NT vs. Unix)
Tibor |
|
| Back to top |
|
|
| kwelch |
| Posted: Mon Oct 28, 2002 7:18 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
So to performance tune what is the best thing to do? I know you can through the assignment tab in the control center set additional instances. I also know that you can make copies of your flow and deploy them. Also, you can make another execution group and assign the messageflow to both execution groups. Does anyone have a feel for which scenario has the best outcome, which takes the most memory, etc.? I will be playing around in my sandbox, but I would like to hear what other folks have done and found to be most effective. Thanks!
Karen |
|
| Back to top |
|
|
|
|
