Problem(Abstract)
Your IBM Integration Bus (IIB) Integration Servers or WebSphere Message Broker (WMB) Execution Groups appear to be growing in memory indefinitely.
Cause
Misunderstanding of how IIB and WMB deal with memory.
Resolving the problem
When considering memory usage within the DataFlowEngine (DFE) process, there are two sources that the storage is allocated from:
1) The DataFlowEngine main memory heap
2) The Operating System
When a message flow requires storage, then an attempt will be made to allocate the block required from the DataFlowEngines heap. If there is not a large enough contiguous block of storage on the heap, then a request will be made to the operating system to allocate more storage to the DataFlowEngine. If successful, then this will lead to the DataFlowEngines heap growing with the additional storage, and the message flow will use this extra storage.
When the message flow has completed its processing, then it issues a "free" on all its storage and these blocks will be returned to the DataFlowEngines heap ready for allocation to any other DataFlowEngine threads. The storage is NEVER released back to the operating system because there is actually no programmatic mechanism to perform such an operation. The operating system will not retrieve storage from a process until the process is terminated, as the user has observed. Therefore the user will never see the size of the DataFlowEngine process decrease, after it has increased.
When the next message flow runs then it will make requests for storage, and these will then be allocated from the DataFlowEngine heap as before. Therefore there will be re-use within the DataFlowEngines internal storage where possible, minimizing the number of times that the operating system needs to allocate additional storage to the DFE process.
One of the key words in the previous description of memory allocation is contiguous. Most requesters of storage require a continuous chain of blocks in memory. Therefore, it is possible for a message flow to make a request for storage against a heap that does have enough free storage to fulfill the request, but the storage is fragmented, such that the continuous block does not fit into any of the "gaps". In this situation, a request would have to be made to the operating system to allocate more storage to the DFE so that this block can be catered for.
In a multi-threaded environment there will be potentially many threads requesting storage at the same time, meaning that it is more difficult for large block of storage to be allocated. The DataFlowEngine is a multi-threaded process, and so is subject to these type of allocation issues. Even with just one message flow running, it is possible that the instantiation from the first message has not released its storage to the heap before a second instantiation requires similar amounts of storage.
Eventually we would expect the storage usage to plateau, and this situation would occur when the DFE has a large enough heap such that any storage request can be satisfied without having to request more from the operating system.
2) The Operating System
When a message flow requires storage, then an attempt will be made to allocate the block required from the DataFlowEngines heap. If there is not a large enough contiguous block of storage on the heap, then a request will be made to the operating system to allocate more storage to the DataFlowEngine. If successful, then this will lead to the DataFlowEngines heap growing with the additional storage, and the message flow will use this extra storage.
When the message flow has completed its processing, then it issues a "free" on all its storage and these blocks will be returned to the DataFlowEngines heap ready for allocation to any other DataFlowEngine threads. The storage is NEVER released back to the operating system because there is actually no programmatic mechanism to perform such an operation. The operating system will not retrieve storage from a process until the process is terminated, as the user has observed. Therefore the user will never see the size of the DataFlowEngine process decrease, after it has increased.
When the next message flow runs then it will make requests for storage, and these will then be allocated from the DataFlowEngine heap as before. Therefore there will be re-use within the DataFlowEngines internal storage where possible, minimizing the number of times that the operating system needs to allocate additional storage to the DFE process.
One of the key words in the previous description of memory allocation is contiguous. Most requesters of storage require a continuous chain of blocks in memory. Therefore, it is possible for a message flow to make a request for storage against a heap that does have enough free storage to fulfill the request, but the storage is fragmented, such that the continuous block does not fit into any of the "gaps". In this situation, a request would have to be made to the operating system to allocate more storage to the DFE so that this block can be catered for.
In a multi-threaded environment there will be potentially many threads requesting storage at the same time, meaning that it is more difficult for large block of storage to be allocated. The DataFlowEngine is a multi-threaded process, and so is subject to these type of allocation issues. Even with just one message flow running, it is possible that the instantiation from the first message has not released its storage to the heap before a second instantiation requires similar amounts of storage.
Eventually we would expect the storage usage to plateau, and this situation would occur when the DFE has a large enough heap such that any storage request can be satisfied without having to request more from the operating system.
No comments:
Post a Comment