Optimizing flow control for SSM

Optimize the IBM® Spectrum Symphony session manager (SSM) through flow control. Flow control prevents session manager from exhausting critical system resources, which may occur under extreme workload.

About this task

Flow control does the following:
  • Monitors the status of system resources for session manager:
    • Available memory (physical memory available on the host), in MB.
    • Available virtual address space (for each process), in MB. The maximum configurable size is 8T for 64-bit operating systems (that is, 8388608 MB).
    • Process memory (physical memory available for each process), in MB.
  • Raises the following events when a certain threshold has been reached:
    • NORMAL: Operates in default mode for any new input.
    • PROACTIVE: Gives early warning to system components that can make memory available when required.
    • SEVERE: Starts to scavenge as much memory as possible, current clients work fine.
    • CRITICAL: Starts to slow data inflow to the session manager and raise the priority of getting data out of the session manager. Rejects new connections, suspends new sessions from currently attached clients, and appends new tasks in those suspended sessions (current sessions and tasks are not affected).
    • HALT: Session manager enters into locked mode, so no further processing is allowed until an administrative action is performed, or the system enters a safer state.

Procedure

  1. Edit your application profile. In the SOAM > SSM section, configure values for memory and virtual address space for each threshold.
    Here is an example: 
    <boundaryManagerConfig>
                <boundaries>
                    <boundary elementName="AvailableMemory">
                        <event name="BEV_PROACTIVE" value="50"/>
                        <event name="BEV_SEVERE" value="40"/>
                        <event name="BEV_CRITICAL" value="25"/>
                        <event name="BEV_HALT" value="15"/>
                    </boundary>
                    <boundary elementName="ProcessMemory">
                        <param name="MaxSizeReference" value="8388608"/>
                        <event name="BEV_PROACTIVE" value="40"/>
                        <event name="BEV_SEVERE" value="30"/>
                        <event name="BEV_CRITICAL" value="20"/>
                        <event name="BEV_HALT" value="10"/>
                    </boundary>
                    <boundary elementName=
                        "AvailableVirtualAddressSpace">
                        <param name="MaxSizeReference"
                        value="8388608"/>
                        <event name="BEV_PROACTIVE" value="50"/>
                        <event name="BEV_SEVERE" value="40"/>
                        <event name="BEV_CRITICAL" value="25"/>
                        <event name="BEV_HALT" value="15"/>
                    </boundary>
                </boundaries>
            </boundaryManagerConfig>
    The example illustrates the following configuration settings in the application profile:
    • When available memory on the session manager host is down to 50% of total memory, the event BEV_PROACTIVE is triggered.
    • When available memory is down to 40%, the event BEV_SEVERE is triggered.
    • For available virtual address space, when there is only 50% available virtual address space for the session manager process, BEV_PROACTIVE event is triggered.
    • For process memory, when there is only 40% available memory for the session manager process, BEV_PROACTIVE event is triggered. When available process memory is down to 30%, the event BEV_SEVERE is triggered, and so on.
  2. Save your application profile.
  3. Update your application with the new profile with the soamreg command.

What to do next

Set memory allocation parameters
If the SSM on Linux® remains at a critical memory level when there is enough available memory and not much unfinished workload, the SSM may not be detecting correct memory usage. This can cause the boundary event not to be triggered properly. If this situation occurs, try setting the following environment variables for the SSM in your application profile:
<env name="MMAP_THRESHOLD">131072</env>
<env name="MMAP_MAX">65536</env>
Note: The MMAP_THRESHOLD value should be smaller than the average task input or output size.
Optimize data paging for irrecoverable sessions
To speed up paging and session manager recovery, the specified directory can be on the local drive since the paged data of irrecoverable sessions does not need to be persisted at a shared location.
The following elements and attributes in the SOAM section of the application profile are related to task message data and common data paging for irrecoverable sessions:
  • SOAM > PagingTasksInputNonRec > path
  • SOAM > PagingTasksOutputNonRec > path
  • SOAM > PagingCommonDataNonRec > path
  • SOAM > PagingCommonDataUpdatesNonRec > path
Increase SSM performance by setting SSM to dispatch more than one task to the SIM's service instance queue
Allow the SSM to dispatch tasks faster by increasing the number of tasks no longer queued from the SSM's pending tasks queue, and then dispatched to the SIM, at one time. To enable this feature, under the SOAM > SessionTypes section of the application profile, set maxQueuedTasksAtSim to 1 or more (by default, it is 0). Once enabled, then minQueuedTasksAtSim is used and defaults to 1. If you set maxQueuedTasksAtSim to 1 or more, also ensure it is greater than or equal to minQueuedTasksAtSim.

To disable this feature, set maxQueuedTasksAtSim to 0. This is the default. Once disabled, then minQueuedTasksAtSim is ignored.

For example, to set SIM to queue at least two pending tasks, and up to ten pending tasks, set the following in your application profile:
<SessionTypes>
<Type name="MySession"
	abortSessionIfTaskFail="false"
		abortSessionIfClientDisconnect="true"
		persistTaskHistory="all"
		priority="1"
		recoverable="true"
		sessionRetryLimit="3"
		taskCleanupPeriod="100"
		maxQueuedTasksAtSim="10" minQueuedTasksAtSim="2"
		suspendGracePeriod="100" taskRetryLimit="3"/>
</SessionTypes>
Note: This feature is optimized for short task run times (that is, tasks less than one second long). When this feature is enabled, the SSM allocates a minimum number of slots so that all queues are full. However, if you have a small number of tasks, and many free slots, this feature does not utilize all slots.
The formula to calculate the minimum number of slots that SSM allocates, is as follows:
  1. If the number of slots is more than (total tasks)/(maxQueuedTasksAtSim+1), SSM will use the value of (total tasks)/(maxQueuedTasksAtSim+1) as the number of slots to use.
  2. If the number of slots is less than (total tasks)/(maxQueuedTasksAtSim+1), all the slots will be used.