Settings related to the application and resources assigned to the consumer associated with the application.
Name of the application associated with the consumer. The application name must be unique within the cluster.
Enclose the application name in double quotes if it contains spaces, for example, name="Commodity Derivatives App".
In the Platform Management Console: Accepts "a-z, A-Z, 0-9 or spaces. Do not use "all" as an application name—it is a reserved word.
On the command line: Accepts all ASCII printable characters except "\ / : * ? ’ | & < or >". Does not accept leading or trailing spaces in application names. Do not use "all" as an application name—it is a reserved word.
Name and path of the consumer with which to associate this application. The consumer must already exist in Symphony. The consumer you associate with the application determines how Symphony allocates resources to the application.
The consumer ID includes the path to the consumer within the consumer tree.
The consumer must be a leaf consumer. A leaf consumer always resides at the lowest level of the consumer tree.
A unique consumer ID must be specified in Symphony, but it is not required to be pre-defined in SymphonyDE. SymphonyDE uses the consumer ID to associate applications and service packages. Only one application can be enabled within a consumer ID and service packages must be deployed to the same consumer ID.
Resource group from which resources are requested to run service instance managers and services to perform computations for clients. The resource group should contain compute hosts, not management hosts. The resource group name can contain multiple resource groups, e.g., "rg1 rg2 rg3".
numOfSlotsForPreloadedServices—Defines the number of slots required for service instances that are prestarted if preStartApplication is true. The number cannot be greater than the number of slots available in the resource groups, defined by resourceGroupName
resourceGroupFilter—Defines a list of resource groups from which the session can use resources. This list either matches or is subset of the resource groups specified in resourceGroupName.
Specifies the criteria for selecting the resources. The selection string filters out the resources that do not meet the criteria, resulting in a list of one or more eligible resources.
Specifies the sort order for selecting the best resource from the list of eligible resources. The most appropriate resource is listed first, the least is listed last.
The selection string is a logical expression used to select one or more resources to match one or more criteria. Any resource that satisfies the criteria is selected.
The following resources can be used as selection criteria.
Static resources are built-in resources that represent host information that does not change over time, such as the maximum RAM available to user processes or the number of processors in a machine. Most static resources are determined at start-up time, or when hardware configuration changes are detected.
Static resources can be used to select appropriate hosts based on binary architecture, relative CPU speed, and system configuration.
The CPU factor is the speed of the host’s CPU relative to other hosts in the cluster. If one processor is twice the speed of another, its CPU factor should be twice as large. CPU factors are defined by the cluster administrator. For multiprocessor hosts, the CPU factor is the speed of a single processor.
The server static resource is Boolean. It has the following values:
Specifies the value to be used as criteria for selecting a resource. Value can be numerical, such as when referring to available memory or swap space, or it can be textual, such as when referring to a specific type of host.
Sorts the selected resources into an order of preference according to the values of the resources.
The order string acts on the results of a select string, sorting the selected resources to identify the most favorable resources, and eliminate the least desirable resources.
Resources are sorted into ascending order based on the result of an arithmetical expression.
Specifies the workload scheduling policy used. The scheduling policy determines how and when Symphony allocates resources to run services for the application.
taskHighWaterMark—Defines the maximum ratio of unprocessed tasks to CPU slots before more resources are requested.
taskLowWaterMark—Defines the minimum ratio of unprocessed tasks to CPU slots before unused resources are released.
resourceBalanceInterval—Defines when Symphony next checks to determine whether resources need to be requested or released from Platform EGO.
sessionSchedulingInterval—Determines when resources are balanced among sessions.
Applies to the whole application. The ratio represents the total number of pending and running (unprocessed) tasks in open sessions to service instances. The value of taskHighWaterMark is fixed at 1; this means that for every unprocessed task, 1 CPU slot is requested (assuming the session has a service-to-slot ratio of 1:1).
In Symphony DE, the number of CPU slots on a host is configured in the conf/vem_resource.conf file under the Symphony DE installation directory.
In Symphony, the number of CPU slots on a host is configured in the ResourceGroups.xml file through the PMC.
resourceBalanceInterval—Defines when Symphony next checks to determine whether resources need to be requested or released from Platform EGO
taskLowWaterMark—Defines the minimum ratio of unprocessed tasks to CPU slots before unused resources are released
serviceToSlotRatio—Defines the number of slots required to run a service instance
Applies to the whole application. Ratio is used to determine whether idle CPU slots are released and made available for other applications to use. Once the ratio of unprocessed tasks to service instances falls below the taskLowWaterMark, resources are released and made available for other applications to use.
If taskLowWaterMark is 1.0, any resources the application releases must be idle. For example, you have thousands of unprocessed tasks. 100 CPU slots are allocated to the Session Manager. Note that this example assumes the session has a service-to-slot ratio of 1:1.
When the number of unprocessed tasks reaches 200, the ratio of unprocessed tasks to CPU slots is 200/100= 2. The Session Manager does not release any CPU slots.
When the number of unprocessed tasks reaches 100, the ratio of unprocessed tasks to CPU slots is 100/100=1. The Session Manager does not release any CPU slots.
When the number of unprocessed tasks drops below 100, the Session Manager releases slots until the ratio becomes greater than 1.
If taskLowWaterMark is equal to 0, the application never returns resources voluntarily.
resourceBalanceInterval—Defines when Symphony next checks to determine whether resources need to be requested or released form Platform EGO
taskHighWaterMark—Defines the maximum ratio of unprocessed tasks to CPU slots before more resources are requested
serviceToSlotRatio—Defines the number of slots required to run a service instance
Minimum number of seconds between checks to determine whether the session manager should release unused resources or request additional resources for the application.
resourceGroupName—Defines the resource groups available to an application
sessionSchedulingInterval—Determines when resources are balanced among sessions
taskHighWaterMark—Defines the maximum ratio of unprocessed tasks to CPU slots before more resources are requested
taskLowWaterMark—Defines the minimum ratio of unprocessed tasks to CPU slots before unused resources are released
Minimum number of milliseconds between checks to determine whether compute resources need to be reallocated among sessions.
The system reallocates resources according to application session priority, scheduling policy, and pending tasks.
Specifies whether the session manager, service instance manager, and service instances are prestarted for enabled applications when Symphony is started, or when an application is enabled.
Specifies whether resources that have been allocated to the application will have standby services running when slots are released by the SSM. Note that standby services are not supported by Symphony DE. In this case, standby service configuration is ignored by Symphony and a warning message is logged.
Number of seconds the session manager waits for the client to reconnect when the connection between the client and session manager is broken.
When abortSessionIfClientDisconnect is true, sessions which are open on the client connection are aborted if a disconnected client does not reconnect to the session manager.
The transientDisconnectionTimeout counter is reset when a client connects or re-connects to the session manager. Reconnection is done by the Symphony Client API, which is transparent to the client application.
Used for recoverable sessions. Specifies whether or not the session manager caches data before writing to disk.
When set to true, data is not cached, it is immediately written to disk. When set to false, data is cached before it is written to disk. Note that the setting in flushDataAsap does not affect any operating system configuration. You need to disable write-behind caching for your operating system. On Windows, see http://support.microsoft.com/kb/247485 for more details. On Linux, contact your system administrator.
Specifies the amount of time that unassigned services will remain idle with the application before releasing their corresponding slot to EGO (and terminating the service). An unassigned service is defined as a service not assigned to any session. If new workload arrives before the configured time elapses, these unassigned services can be used to handle the new workload. Once an unassigned service becomes assigned to a session again, its idle timer is reset.
Specifies whether selective reclaim is enabled.
A value of "true" means selective reclaim is enabled. Selective reclaim allows you more control over which task is interrupted during resource reclaim, because the system uses preemption rank and preemption criteria (both configurable) to determine which host supplies the resource.
Without selective reclaim, the host is selected at random but the SSM uses preemption criteria and preemption rank to choose which slots are reclaimed on that host.
Specifies the policy used to decide which task to interrupt to reclaim a resource.
This setting affects the resource reclaim process when the system has identified multiple sessions or tasks that could provide a resource, even after considering preemption rank or session priority.
If the value is set to MostRecentTask, the system selects the task with the least run time, and reclaims the resource used by that task. If multiple tasks have the same run time, the system selects any one at random. If multiple tasks run on a slot, consider the cumulative run time of all tasks using the slot.
If the workload scheduling policy (session scheduling policy) is proportional or minimum services, and the value is set to Default, the system selects the most overallocated session, and reclaims a resource used by that session. If multiple sessions are equally over-allocated, the system selects any one at random. If no session is over-allocated, select the least under-allocated instead. Task selection is random.
If the workload scheduling policy (session scheduling policy) is priority, and the value is set to Default, the system selects a task at random.
Determines whether resource-aware scheduling for sessions and/or data-aware scheduling for tasks are enabled. When set to ResourceAware, the SSM collects host attributes and evaluates them against a resource preference expression for the session. When set to DataAware, the SSM collects data attributes of services instances and hosts and evaluates them against a user-defined preference expression for each task. Setting the attribute to DataAware automatically enables resource-aware scheduling for sessions.