I25 loadBalanceDefault.cfg: Difference between revisions

From OuroDev
No edit summary
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
BalanceModeZone Sequential
// Load Balancing Default Configuration
BalanceModeMission Sequential
 
MinAvailPhysicalMemory 500
// The configuration values in this file control how the dbserver
MinAvailPhysicalMemoryBias 0
// tries to balance workload amongst the various host machines
MinAvailVirtualMemory 1000
// made available to it through launcher connections.
PagingLoadLow 0
//
PagingLoadHigh 0
// The dbserver uses these settings in conjunction with metrics
TroubleSuspensionTime 0
// on host utilization and status supplied by the launchers to
MaxMapservers 200
// make decisions on where to best launch server processes such
MaxHostUtilization 300
// as mission maps and static zones.
StaticCPUBias 0
//
StartingStaticMemBias 0
// The load balancing settings presented here should reflect the
StartingStaticCPUBias 0
// provisioning of the launcher host machine and its environment;
StartingMissionMemBias 0
// e.g., network capacity, cpu cores, available virtual memory, disk speed etc.
StartingMissionCPUBias 0
//
SecondaryRoleBias 0
// The primary goal of the load balancing is to insure survivability
MinPhysicalMemory 0
// of the service and host stability. These settings, in conjunction with
MinVirtualMemory 0
// servers.cfg settings, can be used to setup an occupancy limits on
SuspensionTime 0
// host machine resources. When those limits are exceeded the service will
MaxMapservers_LowWaterMark 0
// suspend using individual hosts and even enter a system wide overload
MaxHostUtilization_LowWaterMark 0
// protection mode.
MinVirtualMemory_LowWaterMark 0
//
// The secondary goal is to provide adequate Quality of Service (QoS)
// to the players by distributing load to make the service sufficiently
// responsive.
//
// The Live environment consists of pool of host machines that are
// shared by all the dbservers. Load balancing is more challenging
// in this scenario as an individual dbserver is unaware of the
// impact of the actions of the other dbservers until it receives
// new status updates from mahcines in the host pool.
// The quality of the status snapshot last received
// on a particular host degrades as the number of dbservers sharing
// that host increase and also during periods of high map launch rates.
//
// Thus, it is best for an individual dbserver working in this configuration
// to treat its knowledge of host status as imperfect and only an approximation.
// Load balancing strategies which employ some randomization can be used to
// improve balancing in this situation.
//
// Note: the most important configuration values are listed first
 
 
// A load balancing "mode" is set by selecting a balancing strategy and
// an associated heuristic for the strategy to use if applicable.
//
// Supported Strategies:
//
//      Sequential      - balance by round robin assignment to the set of available launchers
//      Random          - balance by randomly choosing amongst available launchers
//      RandomChoice    - balance by randomly choosing a set of launchers and selecting the one with minimum heuristic
//      Search          - balance by walking the set of launchers and selecting the one with minimum heuristic
//
// Supported Heuristics:
//
//      Utilization    - a measure of host machine resource utilization (i.e., cpu, etc)
//      TotalOccupancy  - total hosted server count
//      TypeOccupancy  - total hosted server count of a given type (e.g., static or mission)
//
// It is useful to customize the load balancing strategy employed
// according to the type of role a new server process will play.
// Mission maps and bases are inherently transient and usually service
// a small number of players. On the other hand static map zone
// instances can persist indefinitely and can grow to service
// a large number of players.
 
BalanceModeZone Sequential
BalanceModeMission RandomChoice Utilization
 
// Maximum number of maps we allow to start on a given machine.
// Once this limit is reached the host will be suspended and no more
// launches will be permitted.
// The limit applies to the combined static and mission maps counts,
// including maps that are starting up.
// A value of zero disables this check.
MaxMapservers 400
 
// If the amount of virtual memory available to commit (in MB) on the host
// drops below this value the host will be suspended from launching.
// For system stability a generous amount of virtual memory should be available at all times.
// A value of zero disables this check.
MinAvailVirtualMemory 3000 // set to 0 for internal use, but production servers should set to something real like 3000
 
// Maximum host utilization estimate allowed on a host before it is suspended
// from launching any more server processes.
// Individual launcher host utilization is calculated from host performance
// metrics and influenced by settings which follow.
// In general the goal is have a host load of 100 represent that the host
// is humming along at capacity doing 100% useful work.
// However, the host load can be such that it is actually overloaded and the
// host is spending resources paging and servicing too many processes.
// In this case the host utilization values will climb up over 100.
// Host utilization should generally be in the 0 - 200% range.
// See confluence documentation for more details on the calculation
// of this value and guidelines for setting an appropriate maximum.
// A value of 0 disables this form of capacity suspension.
MaxHostUtilization 0
 
// Defines a range of hard fault pages per second that is used to
// map the current paging rate to a percentage which is then added
// to host utilization. This updates utilization when the system
// is busy paging instead of doing real work. Hard faults will
// generally occur as new maps load data and will increase significantly
// once physical memory is exhausted and there are active processes
// that need to have pages swapped into their working sets to operate.
PagingLoadLow 200
PagingLoadHigh 30000
 
// If the amount of available physical memory (in MB) on the host drops below
// this threshold then the associated bias will be applied to the host utilization
// calculation. For example, a bias of .1 implies a 10% increase in host utilization.
MinAvailPhysicalMemory 1000
MinAvailPhysicalMemoryBias 0.10
 
// Amount of memory (in MB) we assume a static/zone map will take once it finishes starting
StartingStaticMemBias 600
 
// Amount of CPU (1 = 100%) we assume a static/zone map will take once it finishes starting
StartingStaticCPUBias 0.30
 
// Amount of memory (in MB) we assume a mission map will take once it finishes starting
StartingMissionMemBias 150
 
// Amount of CPU (1 = 100%) we assume a mission map will take once it finishes starting
StartingMissionCPUBias 0.01
 
// Amount of CPU (1 = 100%) to bias a server by if considering it for it's secondary role
//  If a secondary machine has this many more CPUs available (1.00 = 1 CPU at 100% usage)
//  then the secondary machine will be used instead
// 0.5 is enough so that all of the initial city zones will start on these machines, and the
//  rest should balance nicely
// @todo - deprecated, remove
SecondaryRoleBias 0.5
 
// How much CPU we add on for each static mapserver understanding that they will probably need it.  In the past this was 10%.  That's too high now
StaticCPUBias 0
 
// Amount of time (in seconds) a launcher is suspended if it has a large number of consecutive
// crashes and/or delinks.
// Launchers are also suspended if they stop responding, which gets cleared upon a DbServer restart
TroubleSuspensionTime 1800
</syntaxhighlight>
</syntaxhighlight>

Latest revision as of 19:52, 21 May 2019

// Load Balancing Default Configuration

// The configuration values in this file control how the dbserver
// tries to balance workload amongst the various host machines
// made available to it through launcher connections.
// 
// The dbserver uses these settings in conjunction with metrics
// on host utilization and status supplied by the launchers to
// make decisions on where to best launch server processes such
// as mission maps and static zones.
//
// The load balancing settings presented here should reflect the
// provisioning of the launcher host machine and its environment;
// e.g., network capacity, cpu cores, available virtual memory, disk speed etc.
//
// The primary goal of the load balancing is to insure survivability
// of the service and host stability. These settings, in conjunction with
// servers.cfg settings, can be used to setup an occupancy limits on
// host machine resources. When those limits are exceeded the service will 
// suspend using individual hosts and even enter a system wide overload
// protection mode.
//
// The secondary goal is to provide adequate Quality of Service (QoS)
// to the players by distributing load to make the service sufficiently
// responsive. 
//
// The Live environment consists of pool of host machines that are
// shared by all the dbservers. Load balancing is more challenging
// in this scenario as an individual dbserver is unaware of the
// impact of the actions of the other dbservers until it receives
// new status updates from mahcines in the host pool. 
// The quality of the status snapshot last received
// on a particular host degrades as the number of dbservers sharing
// that host increase and also during periods of high map launch rates.
//
// Thus, it is best for an individual dbserver working in this configuration
// to treat its knowledge of host status as imperfect and only an approximation.
// Load balancing strategies which employ some randomization can be used to
// improve balancing in this situation.
//
// Note: the most important configuration values are listed first


// A load balancing "mode" is set by selecting a balancing strategy and
// an associated heuristic for the strategy to use if applicable.
//
// Supported Strategies:
//
//       Sequential      - balance by round robin assignment to the set of available launchers
//       Random          - balance by randomly choosing amongst available launchers
//       RandomChoice    - balance by randomly choosing a set of launchers and selecting the one with minimum heuristic
//       Search          - balance by walking the set of launchers and selecting the one with minimum heuristic
//
// Supported Heuristics:
//
//       Utilization     - a measure of host machine resource utilization (i.e., cpu, etc)
//       TotalOccupancy  - total hosted server count
//       TypeOccupancy   - total hosted server count of a given type (e.g., static or mission)
//
// It is useful to customize the load balancing strategy employed
// according to the type of role a new server process will play.
// Mission maps and bases are inherently transient and usually service
// a small number of players. On the other hand static map zone
// instances can persist indefinitely and can grow to service
// a large number of players.

BalanceModeZone		 	Sequential
BalanceModeMission		RandomChoice Utilization

// Maximum number of maps we allow to start on a given machine. 
// Once this limit is reached the host will be suspended and no more
// launches will be permitted.
// The limit applies to the combined static and mission maps counts,
// including maps that are starting up.
// A value of zero disables this check.
MaxMapservers				400

// If the amount of virtual memory available to commit (in MB) on the host
// drops below this value the host will be suspended from launching.
// For system stability a generous amount of virtual memory should be available at all times.
// A value of zero disables this check.
MinAvailVirtualMemory		3000 // set to 0 for internal use, but production servers should set to something real like 3000

// Maximum host utilization estimate allowed on a host before it is suspended
// from launching any more server processes.
// Individual launcher host utilization is calculated from host performance
// metrics and influenced by settings which follow.
// In general the goal is have a host load of 100 represent that the host
// is humming along at capacity doing 100% useful work.
// However, the host load can be such that it is actually overloaded and the
// host is spending resources paging and servicing too many processes.
// In this case the host utilization values will climb up over 100.
// Host utilization should generally be in the 0 - 200% range.
// See confluence documentation for more details on the calculation
// of this value and guidelines for setting an appropriate maximum.
// A value of 0 disables this form of capacity suspension.
MaxHostUtilization			0

// Defines a range of hard fault pages per second that is used to
// map the current paging rate to a percentage which is then added
// to host utilization. This updates utilization when the system
// is busy paging instead of doing real work. Hard faults will
// generally occur as new maps load data and will increase significantly
// once physical memory is exhausted and there are active processes
// that need to have pages swapped into their working sets to operate.
PagingLoadLow			200
PagingLoadHigh			30000

// If the amount of available physical memory (in MB) on the host drops below
// this threshold then the associated bias will be applied to the host utilization
// calculation. For example, a bias of .1 implies a 10% increase in host utilization.
MinAvailPhysicalMemory		1000
MinAvailPhysicalMemoryBias	0.10

// Amount of memory (in MB) we assume a static/zone map will take once it finishes starting
StartingStaticMemBias	600

// Amount of CPU (1 = 100%) we assume a static/zone map will take once it finishes starting
StartingStaticCPUBias	0.30

// Amount of memory (in MB) we assume a mission map will take once it finishes starting
StartingMissionMemBias	150

// Amount of CPU (1 = 100%) we assume a mission map will take once it finishes starting
StartingMissionCPUBias	0.01

// Amount of CPU (1 = 100%) to bias a server by if considering it for it's secondary role
//  If a secondary machine has this many more CPUs available (1.00 = 1 CPU at 100% usage)
//  then the secondary machine will be used instead
// 0.5 is enough so that all of the initial city zones will start on these machines, and the
//  rest should balance nicely
// @todo - deprecated, remove
SecondaryRoleBias	0.5

// How much CPU we add on for each static mapserver understanding that they will probably need it.  In the past this was 10%.  That's too high now
StaticCPUBias		0

// Amount of time (in seconds) a launcher is suspended if it has a large number of consecutive 
// crashes and/or delinks.
// Launchers are also suspended if they stop responding, which gets cleared upon a DbServer restart
TroubleSuspensionTime		1800