IBM Integration Bus Configuration recommendations to reduce memory usage
The first Good Operating Practice document has been published.
The good operating practices information in the following sections share common approaches to solving common problems based on real environments. They do not provide a “one size fits all” solution. They assume that you have a basic understanding of IBM Integration Bus. As technology evolves, new recommendations and information might be added to the information in these documents.
How do I get this document?
Watch the video that introduces the recommendations: http://bit.ly/1EhWt3g
Read the online version in the product documentation: http://ibm.co/1tCHopO
What does this document cover?
The major influence on the amount of memory that is used in processing data is the combination of the messages that are being processed, and how the flow is designed. However, the configuration of the integration broker runtime also has a significant effect on the memory usage, and so we can’t ignore that either.
We talk about Deploying message flows to integration servers. Every message flow has a memory requirement that depends on the routing or transformation logic that is run and the messages to be processed. So, if you use an extra instance of a message flow, the memory usage obviously rises. But the memory usage for the instance is lower than if you deploy another identical flow to a different integration server. If you deploy integration flows that are different from each other to an integration server, then more virtual memory and real memory is used by that integration server.
So we offer some recommendations on this and how to measure the memory requirements while you plan your flow.
Then we move on to configuring the JVM settings for the integration server. The default settings of the JVM are sufficient for most situations. But, as your requirements on message flow logic or nodes grows, the settings must be adjusted to ensure continued levels of service.
We give a little guidance on these settings and garbage collection statistics.
Then we come to Balancing the number of integration servers. While an integration node can support any number of integration servers, practical limitations such as the amount of memory or swap space do force a maximum limit on us to ensure continued levels of service. We talk about the effect on memory that the number of integration servers has on the integrations nodes. As well as the practical reasons why you shouldn’t just throw all the integration servers onto a single node.
And finally, we have a Strategy section that ties in with this balancing. We describe when you should group message flows together and when you shouldn’t, how you might divide up your flows based on the work that they do, and the memory costs of deploying.