Author |
Message
|
mq_crazy |
Posted: Fri Nov 11, 2005 8:00 am Post subject: Load balancing |
|
|
 Master
Joined: 30 Jun 2004 Posts: 295
|
I have this two servers MQ clustered and the application putting messages are load balanced between the queue that is defined on the two server queue managers, but the issue is the server1 has lot of process load almost 90-100% and server 2 has load of just below 10%. How can i not only just round robin the messages but also check their process level and distribute accordingly?? |
|
Back to top |
|
 |
bower5932 |
Posted: Fri Nov 11, 2005 9:17 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
WMQ v6 has added some options to the clustering to try and distribute messages a little better based on the machine's capability. What version of WMQ are you using? |
|
Back to top |
|
 |
wschutz |
Posted: Fri Nov 11, 2005 10:02 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Quote: |
How can i not only just round robin the messages but also check their process level and distribute accordingly?? |
What bower says is true, but the new features do not do workload management, that is, with V6 you can say: send 2 times more messages to Machine A than Machine B because machine A can process them twice as fast, but there is no feedback mechanism incase Machine A gets a backlog.
For something like that, you'd need to write your own workload management exit (not easy!). _________________ -wayne |
|
Back to top |
|
 |
markt |
Posted: Fri Nov 11, 2005 10:16 am Post subject: |
|
|
 Knight
Joined: 14 May 2002 Posts: 508
|
You wouldn't necessarily have to write a WLM exit, as you could have a program on each machine that does something like looking how busy it is and then issuing the appropriate MQSC command to change the weighting of the qmgr/channel.
But by the time you've done that, and the update has been distributed to the sending machine, then the load has probably changed.
If the load is constantly so different between the two boxes, then using the V6 cluster weighting values as static attributes would be sufficient. |
|
Back to top |
|
 |
wschutz |
Posted: Fri Nov 11, 2005 10:23 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Quote: |
You wouldn't necessarily have to write a WLM exit, as you could have a program on each machine that does something like looking how busy it is and then issuing the appropriate MQSC command to change the weighting of the qmgr/channel.
|
So no restart of the channel would be necessary for the changed values to take effect? _________________ -wayne |
|
Back to top |
|
 |
mq_crazy |
Posted: Fri Nov 11, 2005 10:33 am Post subject: |
|
|
 Master
Joined: 30 Jun 2004 Posts: 295
|
Thanks for the replies guys. We are using MQ5.3 on win 2003 server. I don't think we are in a position to upgrade to 6.0 now, so is there any way in the 5.3 version to get this resolved?? Also we have the server1 max uncommitted mesages parameter set as 3 times more than server2, would that effect that??? |
|
Back to top |
|
 |
wschutz |
Posted: Fri Nov 11, 2005 10:40 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
With V5.3, your only choice is a workload mgmt exit.
Max uncommitted msgs only takes effect if your application has that many messages in a single unit of work, in which case it'll get an error. I don't think it will affect you unless that happens. _________________ -wayne |
|
Back to top |
|
 |
mq_crazy |
Posted: Fri Nov 11, 2005 10:57 am Post subject: |
|
|
 Master
Joined: 30 Jun 2004 Posts: 295
|
Thanks wshutz for the answer. I am not good at writing those. Do you recommend any third party that sell these??? |
|
Back to top |
|
 |
Mr Butcher |
Posted: Fri Nov 11, 2005 11:05 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
it is not only the number of queues that the default workload mechanism takes into account when it assigns the messages to the target queues, but also the number of channels to the queues.
define a second cluster receiver channel on the server that should get more data, now server A has 1 channel and server B has 2 channels, server A will get 1 message, server B will get 2 messages. _________________ Regards, Butcher |
|
Back to top |
|
 |
hopsala |
Posted: Sat Nov 12, 2005 6:26 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
mq_crazy wrote: |
Thanks wshutz for the answer. I am not good at writing those. Do you recommend any third party that sell these??? |
You have three options:
1. Search the internet for samples (I haven't been able to find one personally, but I just searched for 2 min)
2. Maybe someone here will be willing to give you a sample code.
3. As for buying options - You could approach Roger (user RogerLacroix - see the CapitalWare forum) - He has been fiddling around with WMQ exits for quite some time, possibly with the wlm exit as well, and might be interested to write/supply one for you. He knows his stuff, so he would be a very good vendor choice. (ps- I have no ulterior motive here) |
|
Back to top |
|
 |
EddieA |
Posted: Sat Nov 12, 2005 11:37 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
There's also a SupportPac that might give you a head start.
But how is the server where the messages are put going to the the current workload of the recipient servers.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sat Nov 12, 2005 12:25 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Do you really care that Server1's CPU is high? Is the Input queue on Server1 staying at zero like the Input queue on Server2? If it is, then don't try and solve a server's performance problems with MQ.
If the queue is backing up on Server1, then the Workload Exit only needs to check the queue depths, rather the CPU utilization, which is a lot easier. BUT, guess why the base cluster workload algorithim doesn't check destination q depths? Because it kills the performace of the MQ cluster round robining (it would constantly be waiting for a list of all the q depths before making the next decision).
Sounds to me like you should be asking, why is Server1's CPU so high, and fix that problem, instead of going down this path. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|