Q). Why is memory not freed after deleting a message in RTclient?Q). I am seeing a lot of memory growth in one or more of my SmartSockets processes.
Article ID: KB0087623
Updated On:
| Products | Versions |
|---|---|
| TIBCO SmartSockets | - |
| Not Applicable | - |
Description
Resolution:
To increase performance SmartSockets manages its own internal pools (one per thread) for allocating and freeing (creating & destroying) messages. This memory is allocated by calling TipcSrvMsgNext. The pools are defined in terms of number of messages they can hold. If a process uses very large messages then the size of these pools, in terms of memeory, can become excessive. There is an undocumented option, _msg_pool_max_size, which controls the number of messages that can be held in the pool. Note that since this functionality is associated with Tmsg* it true of both RTservers and RTclients. To disable message pooling so as to ensure all memory allocated for messages will be immediately freed after the call to TipcMsgDestroy set the following option:
setopt _msg_pool_max_size 0.0 // The option takes a real number which is caste to T_INT4 .
By default with a call to TipcMsgDestroy returns the memory allocated for each message to the heap rather than actually being freeing the memory. This can help improve performance when an application creates and destroys large volumes of small messages.
The default value of _msg_pool_max_size was 1024 under SmartSockets 5.X and lowered to 100 in SmartSockets 6.X.
In 6.5.1 cumulative fix 3 this value is changed to 0 (the internal pool is disabled). Starting with SS 6.6.0 the default will be 10, and an additional undocumented option has been added, _msg_pool_max_msg_size. This new option controls the maximum size of a message that can to be cached. Anything greater than this size will not be cached, just destroyed. The default is 10k.
So with the default settings in SS 6.6.0+ the maximum memory that would be available for the message
pool would be 10msgs * 10k = 100k bytes (per thread which creates and destroys messages). By comparison
if an application occasionally managed messages of 1Mb, then the potential memory growth would be
100msgs * 1Mb = 100Mb (per thread).
To increase performance SmartSockets manages its own internal pools (one per thread) for allocating and freeing (creating & destroying) messages. This memory is allocated by calling TipcSrvMsgNext. The pools are defined in terms of number of messages they can hold. If a process uses very large messages then the size of these pools, in terms of memeory, can become excessive. There is an undocumented option, _msg_pool_max_size, which controls the number of messages that can be held in the pool. Note that since this functionality is associated with Tmsg* it true of both RTservers and RTclients. To disable message pooling so as to ensure all memory allocated for messages will be immediately freed after the call to TipcMsgDestroy set the following option:
setopt _msg_pool_max_size 0.0 // The option takes a real number which is caste to T_INT4 .
By default with a call to TipcMsgDestroy returns the memory allocated for each message to the heap rather than actually being freeing the memory. This can help improve performance when an application creates and destroys large volumes of small messages.
The default value of _msg_pool_max_size was 1024 under SmartSockets 5.X and lowered to 100 in SmartSockets 6.X.
In 6.5.1 cumulative fix 3 this value is changed to 0 (the internal pool is disabled). Starting with SS 6.6.0 the default will be 10, and an additional undocumented option has been added, _msg_pool_max_msg_size. This new option controls the maximum size of a message that can to be cached. Anything greater than this size will not be cached, just destroyed. The default is 10k.
So with the default settings in SS 6.6.0+ the maximum memory that would be available for the message
pool would be 10msgs * 10k = 100k bytes (per thread which creates and destroys messages). By comparison
if an application occasionally managed messages of 1Mb, then the potential memory growth would be
100msgs * 1Mb = 100Mb (per thread).
Issue/Introduction
Q). Why is memory not freed after deleting a message in RTclient?Q). I am seeing a lot of memory growth in one or more of my SmartSockets processes.
Feedback
Yes
No
Powered by
