Introduction
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 message flow is designed. However, the configuration of the integration node runtime also has a significant effect on the memory usage, and it cannot be ignored.
The message flow logic and product code of an integration server all use virtual memory. The message tree, variables, and output messages are all held at locations within virtual memory as they are processed, therefore the entire process size of the integration node does not need to be held in physical memory at the same time. Integration servers that are configured differently and have different message flows deployed to them, use different amounts of both virtual and real memory; there is not an assigned default amount of memory for each integration server.
When processing begins, a subset of the virtual memory that is allocated to an integration server must be in real memory when that data is processed (read or updated) with ESQL or Java™ for example. This set of essential memory is what forms the real memory requirement, the working set, of the integration server. The contents of this working set change over the lifetime of the integration server.
The whole working set must be in real memory for message processing to continue smoothly. If required pages are moved into real memory during processing, then this movement causes delays in processing. In a system under heavy load, the operating system must manage the movements of pages quickly. This behavior can slow down processing for one or more components because the demand for real memory is higher than the memory that is physically available. In extreme circumstances, the system might thrash and complete no actual useful work.
The working set requirements of all the integration servers that are running, plus the memory that is required by the bipservice, bipbroker, and bipHTTPListener processes form the total real memory requirements of the integration node. As message flows and integration servers are started and stopped, the real memory requirement changes. The overall real memory requirement for a fixed configuration and workload usually remains within a narrow band of usage, with only slight fluctuations. If the real memory requirement continues to grow, then there is probably a memory leak. This memory leak might be in the integration logic, or in some rare cases, in the IBM® Integration Bus product.
The memory requirement for an integration node is entirely dependent on the processing that must be carried out. If all integration servers were stopped, the real memory requirements would be smaller. The integration servers would still have their initial memory footprint, as well as the memory needed for tasks that do not involve processing messages, such as processing a deploy. So, if 50 integration servers were active and processing with inefficient message flows to process large messages, then real memory requirements might rise to 10's of gigabytes in size. As withintegration servers, there is no fixed memory requirement for an integration node. The memory requirement depends on which message flows are running, and the configurations of the integration node.