LB Manager
Manage load balancers.
The LB manager component vt::, accessed via vt:: manages and coordinates instances of load balancers. It will potentially start load balancing after a "phase" is completed; refer to Phase Manager for details about how to delineate phases in an application. The LB manager reads command-line arguments or an LB specification file to determine which load balancer to run at a given phase.
To enable load balancing, the cmake flag -Dvt_lb_enabled=1 should be passed during building. This also enables automatic instrumentation of work and communication performed by collection elements.
To run a load balancer at runtime:
- Pass
--vt_lb --vt_lb_name=<LB>as a command line argument - Write a LB config file
--vt_lb --vt_lb_file_name=<FILE> - One can also pass
--vt_lb_self_migrationas a command line argument to allow load balancer to migrate objects to the same node
Note that one should use either --vt_lb_name or --vt_lb_file_name option, not both.
LB Config File
The LB config file allows users to specify which load balancer along with which LB-specific configuration parameters are passed to the load balancer instance for any given phase. The order of the LB phase specification lines in the file disambiguates lines—higher precedence for earlier lines.
The format of the LB config file is:
[%] <$phase> <$lbname> [$LB-specific-arg-1] ... [$LB-specific-arg-N]
If a % is present, the line matches phases where: current phase % $phase == 0. Phase-specific lines (ones that specify a load balancer without a %) always always have precedence over % lines. The next token after the optional % and $phase is the name of the load balancer to invoke on that phase. After the load balancer name, N arguments to the load balancer are allowed to customize how the load balancer is run with the format of key=value. These arguments are the equivalent of passing --vt_lb_args="A=test B=test2" on the command line.
The following is an example LB config:
%10 TemperedLB c=1 k=5 f=2 i=10 0 HierarchicalLB min=0.9 max=1.1 auto=false % 5 GreedyLB min=1.0 120 GreedyLB c=0 k=2 f=3 i=3
To print LB config during startup, use --vt_lb_show_config command line flag.
Load balancers
| Load Balancer | Type | Description | Reference |
|---|---|---|---|
| RotateLB | Testing | Rotate objects in a ring | vt:: |
| RandomLB | Testing | Randomly migrate object with seed | vt:: |
| GreedyLB | Centralized | Gather to central node apply min/max heap | vt:: |
| TemperedLB | Distributed | Inspired by epidemic algorithms | vt:: |
| HierarchicalLB | Hierarchical | Build tree to move objects nodes | vt:: |
| ZoltanLB | Hyper-graph Partitioner | Run Zoltan in hyper-graph mode to LB | vt::vrt::collection::lb::ZoltanLB |
| OfflineLB | User-specified | Read file to determine mapping | vt:: |
| TestSerializationLB | Testing | Migrate objects to the same node, for testing serialization/deserialization purpose | vt:: |
Object Load Models
The performance-oriented load balancers described in the preceding section require a prediction of the loads each object will represent during the phases between one load balancing invocation and the next. These predictions are provided by load models, which are implementations of the vt::vrt:collection::balance::LoadModel interface. There are a number of general-purpose load model implementations provided by vt.
By default, vt uses a load model that predicts each object's work load for all future phases will match its workload in the most recent past phase. The system also provides an interface for applications and users to arrange use of a non-default load model where that may be desirable for reasons such as performance experimentation, specialization to application details, or execution environment considerations. To install a custom load model, application code should call vt::. To simplify implementation of custom load models, and allow them to benefit from future system-level improvements, we recommend that custom load models be composed atop the default model, which can be obtained by calling vt::.
Most provided load models are designed as composable filters inherited from the vt::vrt:collection::balance::ComposedModel class. This allows them to form a 'model stack' in which each class makes a particular adjustment to the predictions generated, and relies on others above and below to refine them further. One exception is the vt::vrt:collection::balance::RawData model, which directly returns past values recorded in the instrumented statistics structures that LBManager provides.
To illustrate the design concept, the default model is implemented as a stack of two other components. At the base of the stack is a RawData model that will refer to the instrumented object load timings recorded by the system during preceding execution. Layered on that is a vt::vrt:collection::balance::NaivePersistence model that queries the underlying RawData model for the times taken in the most recent phase, and returns those same times as its prediction of the times those objects will take in all future phases.
The full set of load model classes provided with vt is as follows
| Load Model | Description | Reference |
|---|---|---|
| Utilities | ||
| LoadModel | Pure virtual interface class, which the following implement | vt:: |
| ComposedModel | A convenience class for most implementations to inherit from, that passes unmodified calls through to an underlying model instance | vt:: |
| RawData | Returns historical data only, from the measured times | vt:: |
| Transformers | Transforms the values computed by the composed model(s), agnostic to whether a query refers to a past or future phase | |
| Norm | When asked for a WHOLE_PHASE value, computes a specified l-norm over all subphases | vt:: |
| SelectSubphases | Filters and remaps the subphases with data present in the underlying model | vt:: |
| CommOverhead | Adds a specified amount of imputed 'system overhead' time to each object's work based on the number of messages received | vt:: |
| PerCollection | Maintains a set of load models associated with different collection instances, and passes queries for an object through to the model corresponding to its collection | vt:: |
| Predictors | Computes values for future phase queries, and passes through past phase queries | |
| NaivePersistence | Passes through historical queries, and maps all future queries to the most recent past phase | vt:: |
| PersistenceMedianLastN | Similar to NaivePersistence, except that it predicts based on a median over the N most recent phases | vt:: |
| LinearModel | Computes a linear regression over on object's loads from a number of recent phases | vt:: |
| MultiplePhases | Computes values for future phases based on sums of the underlying model's predictions for N corresponding future phases | vt:: |
All of the provided load balancers described in the previous section require that the installed load model provide responses to future phase queries for at least PhaseOffset::NEXT_PHASE (i.e. 0), as the Predictors described above do.