| Author |
Message
|
| mverh |
 Posted: Thu Dec 12, 2002 6:47 am Post subject: How many brokers can a single ConfigMgr support |
 |
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
All, I have come across an interesting issue.
Environment:
W2K/WMQI V2.1 CSD02/WMQ V5.3.1
At my site we have a test config manager. This ConfigMgr now supports 6 brokers, we have 3 different test environments, i.e. integration test, user acceptance test etc where 2 brokers are clustered for each environment. This ConfigMgr will likely need to support more brokers in the future. We have many message sets (20+) and many flows (40+).
What we have discovered is that when a deploy to an individual broker fails for some reason that causes the ConfigMgr to think that the deploy is still outstanding and we have to do a forced deploy to override this situation the forced deploy fails with an jvm memory problem. We have bumped the ConfigMgr maxjvmheapsize to a huge number (1.6G) but this hasn't solved the problem.
I am wondering if other users have encountered this and what they did to overcome the inability to do a forced deploy.
Just so you know we update the CBROKER table and change the CSECTION value for the broker in question to some goofy value from DPLING and then do a deploy complete for the individual broker. Which makes me wonder why WMQI doesn't give us the ability to do a forced deploy at an individual broker level? Why must I force deploy all brokers in a given ConfigMgr?
Marc Verhiel
Cande Corp. |
|
| Back to top |
|
 |
| udaybho |
| Posted: Thu Dec 12, 2002 8:08 am Post subject: |
|
|
Voyager
Joined: 09 May 2002
Posts: 94
Location: Chicago
|
I do not think IBM put any limitations on how may brokers you can control using a Config Manager. As long as you have connectivity with remote Broker Queue Manager you can manage the brokers.
Regarding your problem please check the broker log, you may get some clue there.
Config Manager acts as Post office to carry deployment information to broker.
I am desiging a system where I may have to manage thousands of broker from a Config Manager. Its a challenge though !!!
Uday Bhosle |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Dec 12, 2002 9:42 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
The broker is not the problem here. The admin message from the ConfigMgr never gets created because of the ConfigMgr jvm problem, hence no message ever gets sent to the broker.
The question is how many brokers of what kind of configuration i.e. how many message sets of size x and flows can a single ConfigMgr manage in practice.
The theoretical limit is nice to know but doesn't matter to me since I'm at 6 brokers and I can no longer perform a forced deploy... |
|
| Back to top |
|
|
| udaybho |
| Posted: Thu Dec 12, 2002 10:05 am Post subject: |
|
|
Voyager
Joined: 09 May 2002
Posts: 94
Location: Chicago
|
The way I understand the Contol center creates Admin Messages and COnfig Manager helps them to channel it to proper broker.
Do you want to say that your Control Center is corrupted ? Did you tried it form other contol center ? Try installing control center again. If your deployment with other broker is going fine I even won't reinstall control center.
From your post it looks like you have problem with only one broker. I will look into that broker first. |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Dec 12, 2002 11:08 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
I don't think you understand my question.
I have no problem with any broker. I have had times where the admin message from the ConfigMgr to the broker has been lost or the response messages from the broker to the ConfigMgr have been lost. This can happen if for example your xmitqs/qmgr alias queues are defined as DEFPSIST(NO) and the channels between the ConfigMgr and brokers are NPMSPEED(FAST). If this happens the ConfigMgr registers that a deploy is outstanding and therefore you can't re-deploy. To get around this you must do a forced deploy or update the ConfigMgr d/b as mentioned in my earlier post. Now, if you have many brokers being managed by this ConfigMgr the forced deploy is going to cause the ConfigMgr process to consume a lot of memory and you'll likely encounter problems with your jvm.
So, in a nutshell, there is a pratical limit on the number of brokers a single ConfigMgr can support before you start running into problems.
I'm sure you'll encounter this when you start managing your thousands of brokers. |
|
| Back to top |
|
|
| lnm |
| Posted: Thu Dec 12, 2002 12:13 pm Post subject: |
|
|
Apprentice
Joined: 12 Mar 2002
Posts: 43
Location: Florida
|
Let me start by saying I'm not an MQSI admin, but a MQSeries admin, we have run across this same issue.
Here's a couple items that I believe relate.
1. We had several deploy problems in Unit. On Friday of last week and on Monday this week, we tuned the MQSeries environment to accommodate the larger size of messages and this seems to address most of the regular deploy problems.
2. We have discovered that a problem with one execution group (once, Raj's execution group and second Santosh's) affects the entire broker and most often the symptom is that other developers are not able to deploy. Once the problem execution group is recycled, the broker recovers it automatically and things start working fine. We have opened a PMR with IBM on this today, 12/02/2002.
We are wondering if MQSI is really in our future at this point. It looks like we'll have to purchase more licenses in order to move brokers to separate machines.
We wondered if we were the ONLY ones with this issue. |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Dec 12, 2002 1:24 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
On the topic of WMQ tuning wrt to WMQI we do the following:
Channels:
MAXMSGL(104857600)
NPMSPEED(NORMAL) <== not so important
XMITQ/QMGR alias:
MAXMSGL(104857600)
DEFPSIST(YES) <== important
SYSTEM.BROKER.* queues
MAXMSGL(104857600)
Note the MAXMSGL doesn't have to be 100M but the default of 4M will not be sufficient if you have large message sets, a lot of flows and you do a complete deploy.
This way we ensure that we never unintentionally lose a WMQI admin or control message. If you go with vanilla WMQ the WMQI messages will be non-persistent and as a result they could be dropped leaving you in the situation where an outstanding deploy will never complete. |
|
| Back to top |
|
|
| kirani |
| Posted: Fri Dec 13, 2002 10:43 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
It's good practice to increase the max message size for all queue's channels, etc, but I don't think this the problem in your case.
Configuration Manager process has a limit of 2GB for MaxJVMHeapSize parameter. I'd suggest that you avoid doing complete deploy of the topology/broker. Try deploying message sets/flows in a smaller group to the broker and wait until you get some kind of response message from the broker. Watch the memory consumption for your Configuration Manager process while the deploy is going on. If you get BIP1528E message, restart your configuration manager process and resubmit the delta deploy request.
Could you provide following info,
1. How many EG's do you have for each broker?
2. What's your max message set size after export?
3. How much of memory do you have on your box?
4. What lever of CSD you are at?
_________________
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 |
|
|
|
|
