When a new subscriber or publisher application process is added to the node there is inevitably going to be an increase in shared memory usage as each DDS entity that is created must be added to the shared DDS administration. Therefore increasing the amount of subscribers or publishers will increase memory usage. When using shared memory architecture it is important to remember that there is only one copy of a specific sample maintained on the machine at a particular time but the life-cycle of the sample is dependent on QoS settings, such as history, durability e.t.c. and this can affect shared memory usage.

The following QOS policies are some of the policies that can affect shared memory usage:

History ? this can either be set as KEEP_ALL or KEEP_LAST. Having KEEP_ALL history will use more shared memory than KEEP_LAST as more samples will be stored. It is possible to further control shared memory usage while using KEEP_LAST history by using the depth setting. The higher the setting for depth, the more samples kept and so more usage of shared memory.

Reliability ? When reliability is set to RELIABLE then the system will attempt to retransmit any samples that were not made available to a DataReader and so this will use more shared memory than the alternative BEST_EFFORT.

Durability ? the durability QOS determines whether data will be maintained for any late joiners subscribers. For this reason, having the durability kind set to TRANSIENT or PERSISTENT will use more shared memory than VOLATILE.

It is important to use the appropriate QOS settings in order to correctly manage shared memory usage as, for example, having the history as KEEP_ALL when only the last sample is required to be kept will produce unnecessary usage of shared memory.

It is possible to monitor shared memory usage by use of the mmstat tool. For more information on this tool see section 3.4 mmstat Memory Management Statistics of the Deployment Guide in the docs/pdf folder within the OpenSplice directory.