Ranking resource groups in order of preference

When an application can use two or more resource pools and prefers to receive slots from some resource pools over others, rank the resource groups for that consumer in order of preference. With this configuration, the application gets its planned share of resources from each resource group, starting from the one with the highest rank.

How it works

With resource group preference, each resource group for a consumer is tagged with a preference level from "0" up to "MAX_PREFERENCE_LEVEL".

A value of "0" means that this consumer prefers this resource group the most.
A value of "MAX_PREFERENCE_LEVEL" means that this consumer prefers this resource group the least.

You can define a different preference order for each consumer.

When the resource plan permits, consumers always use slots from the preferred resource group before using slots from the less preferred one. If slots in the preferred resource group are borrowed by other consumers but slots are available in the less preferred resource group, EGO reclaim the resources to enforce the preference. It reclaims slots in the preferred resource group before using free slots in less preferred resource groups. If multiple resource groups have the same preference level, a preference is not enforced.

Borrow-only consumers

Borrow-only consumers are consumers without guaranteed slots and are identified by their share ratio, which is always set to 0. When two consumers within a family compete for resources, a borrow-only consumer (and its children) always yields slots to its normal consumer sibling.

A borrow-only consumer has the following characteristics:

When a borrow-only consumer and a normal consumer sibling compete for resources, the borrow-only consumer is not entitled to get resources even if the sibling is also borrowing resources.
A borrow-only consumer's resources are reclaimed if a normal consumer sibling wants to borrow more.
When a borrow-only consumer competes for resource with other consumers that are not its sibling, its parent’s share ratio is taken in to consideration. In this case, the borrow-only consumer does not yield slots to a normal consumer. This means that the borrow-only consumer has greater priority to borrow resources from its family than a normal consumer outside the family.

Resource group preference with borrow-only consumers

With resource group preference, each consumer can be assigned a share ratio of slots per resource group and this share ratio is always honored. A consumer's resource group preference does not override the share ratio, meaning a consumer cannot use more than the resource plan allows even if it prefers the resource group the most.

Explore the following scenarios to understand how share ratio and preference level work together:

When share ratio is greater than 0 and preference level is equal to 0: The consumer owns slots in the resource group and likes to use this resource group first.
When share ratio is equal to 0 and preference level is greater than 0: The consumer is a borrow-only consumer in this resource group and likes to use this group as a secondary resource pool.
When share ratio and preference level are both is greater than 0: The consumer owns slots in the resource group, but likes to use it as a secondary resource pool. One case could be that this consumer owns slots in multiple resource groups and prefers other resource groups.
When share ratio and preference level are both equal to 0: The consumer is a borrow-only consumer for this resource group, but likes to use this resource group first. In this case, the consumer could be a borrow-only consumer for all resource groups and prefers this resource group the most.

Feature interactions

Ownership slots and share pool: When a resource group has both ownership and share ratio policy configured, the ownership policy requirements are satisfied before any slots can be used by the share pool. If total slots in the resource group is not enough to satisfy ownership of all the consumers, then the share pool is empty. A consumer cannot get any slots if it only configured a share ratio.
A consumer can be configured with ownership and share ratio together. In this case, slots configured in ownership are not shared by other consumer unless a lendTo relationship with other consumers is configured.
Static share quota: When static share quota is configured along with preference levels for multiple resource groups, slots are scheduled based on the resource group preference first. Static share quota is considered only within the same preference level.
Standby services: If PreferReclaimAffinity is enabled, slots with the standby service running are scheduled first regardless of the resource group preference.
If standby services are disabled, slots are scheduled by resource group preference first. Standby services are considered only within each resource group.