Author |
Message
|
gabbar |
Posted: Tue Jun 29, 2004 9:46 am Post subject: Deployment problems -- takes too long |
|
|
Acolyte
Joined: 10 Dec 2002 Posts: 50
|
Hi,
We are on WMQI 2.1 CSD 06, brokers on AIX.
We have one messageflow assigned to the execution group with about 600 subflows attached to it.
The messagesets that we are deploying put together are about 60 MB. We have been running into a lot of trouble deploying these to the broker. Its the configmgr thats running into problems. It takes about 25 minutes to deploy a messageset thats 25 mb. Takes about the same time to deploy that huge messageflow. I am talking about just the delta deploy. We could never do a complete deploy on a 35MB messageset. Often, we run into java.lang.outOfMemory issues on the configmgr. We increased java memory heap size to its max on windows, 2 GB. Configmgr hardly gets to 600 MB memory before throwing out of memory exception. The configmgr box has 3GB memory. There are no java apps other than control center and configmgr running on that box.
Has anyone faced similar problems or had to deploy message sets or messageflows that big? Any suggestions to overcome this issue are quite welcome.
Thanks |
|
Back to top |
|
 |
PGoodhart |
Posted: Tue Jun 29, 2004 11:02 am Post subject: |
|
|
Master
Joined: 17 Jun 2004 Posts: 278 Location: Harrisburg PA
|
You may want to try to start with completely new bar files. We found that if you reuse a bar file and remove and replace message flows and message sets the bar files just kept getting bigger and bigger and the deploy got slower with each reuse. We had trival sized deploys that grew to hundreds of mbs. When we started building new bar files from scratch each time we wanted to do a deploy they shrank back down and the deploys went much faster. _________________ Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
Back to top |
|
 |
gabbar |
Posted: Tue Jun 29, 2004 12:19 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002 Posts: 50
|
Quote: |
You may want to try to start with completely new bar files. |
We are not using WBI MB 5.0. So we don't work with bar files.
But we did try something similiar. Recreating the configmgr, clearing the config and MRM DB's contents, importing everything back into the config and MRM databases and deploying one at a time. Didn't help.
Thanks for the reply. |
|
Back to top |
|
 |
kirani |
Posted: Tue Jun 29, 2004 12:31 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
If you do a search in this forum for outofMemory you will find some posts related to similar problem.
First of all practically it's not efficiant to design large message flows/sets. Try to split your processing into smaller group of message flows/sets. It becomes very difficult when deploying such message flows/sets to the broker. How is the performance for this message flow?
My largest messsage set is of 12 MB (.mrp file) size. It takes a while when deploying the message set to the broker. I had to change some of the DB parameters to complete the deploy.
I'd suggest that you redesign your message set and message flow so that it's easier to manage/deploy. _________________ 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 |
|
 |
gabbar |
Posted: Tue Jun 29, 2004 1:40 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002 Posts: 50
|
Kiran,
Thanks for the reply.
I am providing only the infrastructure support for this project and the app developers have already moved code through to UAT. I can only make suggestions which I already did in a similar tone as yours. The message flows and message sets that I ever developed were no where near these sizes. However, its too late for us to make such changes. That has been the last option on our list.
As far as messageflows, we are doing some performance tuning to increase the throughput. I will browse through the forum though to find out if we can atleast avoid those memory issues.
Thanks |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jun 29, 2004 2:17 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Yeah, if you *have* to push big deploys through, then...
You need to make sure that the databases can handle the size and perform reasonably well. All the usual performance optimizations for working with large chunks of data are applicable.
You also need to make sure that the messaging layer can handle it as well. Make sure that all the Broker queues have a MaxMsgLn large enough, as well as the queue manager, and any channels between ConfigMgr and Broker components - and Tooling!
And then you want to make sure that the ConfigMgr and Broker components have sufficient memory in their JVM to handle this.
But, 600 subflows is excessive. I cannot possibly think of a Routing and Transformation function that would need that many subflows in one logical process. Well... Okay. I can think of some.
But I'd still find ways to break it up. It's easy enough to put an MQOutput node right before the connection to the subflow, and then wire a new MQInput node on another flow to the same subflow node.
And I hope, I really really really hope, that they are using RouteToLabel branching instead of layered Filter nodes to choose between all 600 flows.
Otherwise, you will be lucky to process a message in anything that resembles reasonable time. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
gabbar |
Posted: Tue Jun 29, 2004 3:20 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002 Posts: 50
|
I will push for decreasing the complexity of messagesets and message flow(sadly there is just one message flow). Deployment is my problem and I hope THE FLOW and messagesets can be altered.
Thanks Jeff
Thanks for your replies guys
_______________
Gabbar |
|
Back to top |
|
 |
|