diff options
Diffstat (limited to 'site/docs/documentation/Input')
| -rw-r--r-- | site/docs/documentation/Input/Experiment.md | 175 | ||||
| -rw-r--r-- | site/docs/documentation/Input/ExperimentSchema.md (renamed from site/docs/documentation/Input/ScenarioSchema.md) | 0 | ||||
| -rw-r--r-- | site/docs/documentation/Input/FailureModel.md (renamed from site/docs/documentation/Input/FailureModels.md) | 58 | ||||
| -rw-r--r-- | site/docs/documentation/Input/Scenario.md | 125 | ||||
| -rw-r--r-- | site/docs/documentation/Input/Topology.md | 61 | ||||
| -rw-r--r-- | site/docs/documentation/Input/Traces.md | 26 | ||||
| -rw-r--r-- | site/docs/documentation/Input/Workload.md | 24 |
7 files changed, 269 insertions, 200 deletions
diff --git a/site/docs/documentation/Input/Experiment.md b/site/docs/documentation/Input/Experiment.md new file mode 100644 index 00000000..c8b96d1f --- /dev/null +++ b/site/docs/documentation/Input/Experiment.md @@ -0,0 +1,175 @@ +When using OpenDC, an experiment defines what should be run, and how. An experiment consists of one or more scenarios, +each defining a different simulation to run. Scenarios can differ in many things, such as the topology that is used, +the workload that is run, or the policies that are used to name a few. An experiment is defined using a JSON file. +In this page, we will discuss how to properly define experiments for OpenDC. + +:::info Code +All code related to reading and processing Experiment files can be found [here](https://github.com/atlarge-research/opendc/tree/master/opendc-experiments/opendc-experiments-base/src/main/kotlin/org/opendc/experiments/base/experiment) + +The code used to run a given experiment can be found [here](https://github.com/atlarge-research/opendc/tree/master/opendc-experiments/opendc-experiments-base/src/main/kotlin/org/opendc/experiments/base/runner) +::: + +## Schema + +The schema for the scenario file is provided in [schema](ExperimentSchema) +In the following section, we describe the different components of the schema. +Some components of an experiment are not single values, but lists. This is used to run multiple scenarios using +a single experiment file. OpenDC will execute all permutations of the different values. +This means that if all list based values have a single value, only one Scenario will be run. + +| Variable | Type | Required? | Default | Description | +|---------------------|----------------------------------------------|-----------|----------|-------------------------------------------------------------------| +| name | string | no | "" | Name of the scenario, used for identification and referencing. | +| outputFolder | string | no | "output" | Directory where the simulation outputs will be stored. | +| initialSeed | integer | no | 0 | Seed used for random number generation to ensure reproducibility. | +| runs | integer | no | 1 | Number of times the scenario should be run. | +| exportModels | List[[ExportModel](#exportmodel)] | no | Default | Specifications for exporting data from the simulation. | +| computeExportConfig | [ComputeExportConfig](#checkpointmodel) | no | Default | The features that should be exported during the simulation | +| maxNumFailures | List[integer] | no | [10] | The max number of times a task can fail before being terminated. | +| topologies | List[[Topology](#topology)] | yes | N/A | List of topologies used in the scenario. | +| workloads | List[[Workload](#workload)] | yes | N/A | List of workloads to be executed within the scenario. | +| allocationPolicies | List[[AllocationPolicy](#allocation-policy)] | yes | N/A | Allocation policies used for resource management in the scenario. | +| failureModels | List[[FailureModel](#failuremodel)] | no | Default | List of failure models to simulate various types of failures. | +| checkpointModels | List[[CheckpointModel](#checkpointmodel)] | no | null | Paths to carbon footprint trace files. | +| carbonTracePaths | List[string] | no | null | Paths to carbon footprint trace files. | + + +Many of the input fields of the experiment file are complex objects themselves. Next, we will describe the required input +type of each of these fields. + +### ExportModel + +| Variable | Type | Required? | Default | Description | +|----------------|-------|-----------|---------|---------------------------------------------| +| exportInterval | Int64 | no | 300 | The duration between two exports in seconds | + + +### ComputeExportConfig +The features that should be exported by OpenDC + +| Variable | Type | Required? | Default | Description | +|--------------------------|--------------|-----------|--------------|-----------------------------------------------------------------------| +| hostExportColumns | List[String] | no | All features | The features that should be exported to the host output file. | +| taskExportColumns | List[String] | no | All features | The features that should be exported to the task output file. | +| powerSourceExportColumns | List[String] | no | All features | The features that should be exported to the power source output file. | +| serviceExportColumns | List[String] | no | All features | The features that should be exported to the service output file. | + + +### Topology +Defines the topology on which the workload will be run. + +:::info +For more information about the Topology go [here](Topology) +::: + +| Variable | Type | Required? | Default | Description | +|-------------|--------|-----------|---------|---------------------------------------------------------------------| +| pathToFile | string | yes | N/A | Path to the JSON file defining the topology. | + +### Workload +Defines the workload that needs to be executed. + +:::info +For more information about workloads go [here](Workload) +::: + +| Variable | Type | Required? | Default | Description | +|-------------|--------|-----------|---------|---------------------------------------------------------------------| +| pathToFile | string | yes | N/A | Path to the file containing the workload trace. | +| type | string | yes | N/A | Type of the workload (e.g., "ComputeWorkload"). | + +### Allocation Policy +Defines the allocation policy that should be used to decide on which host each task should be executed + +:::info Code +The different allocation policies that can be used can be found [here](https://github.com/atlarge-research/opendc/blob/master/opendc-compute/opendc-compute-simulator/src/main/kotlin/org/opendc/compute/simulator/scheduler/ComputeSchedulers.kt) +::: + +| Variable | Type | Required? | Default | Description | +|------------|--------|-----------|---------|----------------------------| +| policyType | string | yes | N/A | Type of allocation policy. | + +### FailureModel +The failure model that should be used during the simulation +See [FailureModels](FailureModel) for detailed instructions. + +### CheckpointModel +The checkpoint model that should be used to create snapshots. + +| Variable | Type | Required? | Default | Description | +|---------------------------|--------|-----------|---------|---------------------------------------------------------------------------------------------------------------------| +| checkpointInterval | Int64 | no | 3600000 | The time between checkpoints in ms | +| checkpointDuration | Int64 | no | 300000 | The time to create a snapshot in ms | +| checkpointIntervalScaling | Double | no | 1.0 | The scaling of the checkpointInterval after each succesful checkpoint. The default of 1.0 means no scaling happens. | + + +## Examples +In the following section, we discuss several examples of Scenario files. Any scenario file can be verified using the +JSON schema defined in [schema](TopologySchema). + +### Simple + +The simplest scneario that can be provided to OpenDC is shown below: +```json +{ + "topologies": [ + { + "pathToFile": "topologies/topology1.json" + } + ], + "workloads": [ + { + "type": "ComputeWorkload", + "pathToFile": "traces/bitbrains-small" + } + ], + "allocationPolicies": [ + { + "policyType": "Mem" + } + ] +} +``` + +This scenario creates a simulation from file topology1, located in the topologies folder, with a workload trace from the +bitbrains-small file, and an allocation policy of type Mem. The simulation is run once (by default), and the default +name is "". + +### Complex +Following is an example of a more complex topology: +```json +{ + "topologies": [ + { + "pathToFile": "topologies/topology1.json" + }, + { + "pathToFile": "topologies/topology2.json" + }, + { + "pathToFile": "topologies/topology3.json" + } + ], + "workloads": [ + { + "pathToFile": "traces/bitbrains-small", + "type": "ComputeWorkload" + }, + { + "pathToFile": "traces/bitbrains-large", + "type": "ComputeWorkload" + } + ], + "allocationPolicies": [ + { + "policyType": "Mem" + }, + { + "policyType": "Mem-Inv" + } + ] +} +``` + +This scenario runs a total of 12 experiments. We have 3 topologies (3 datacenter configurations), each simulated with +2 distinct workloads, each using a different allocation policy (either Mem or Mem-Inv). diff --git a/site/docs/documentation/Input/ScenarioSchema.md b/site/docs/documentation/Input/ExperimentSchema.md index 78ec55f7..78ec55f7 100644 --- a/site/docs/documentation/Input/ScenarioSchema.md +++ b/site/docs/documentation/Input/ExperimentSchema.md diff --git a/site/docs/documentation/Input/FailureModels.md b/site/docs/documentation/Input/FailureModel.md index d62767f6..ecaf7c03 100644 --- a/site/docs/documentation/Input/FailureModels.md +++ b/site/docs/documentation/Input/FailureModel.md @@ -1,14 +1,18 @@ -OpenDC provides three types of failure models: [Trace-based](#trace-based-failure-models), [Sample-based](#sample-based-failure-models), -and [Prefab](#prefab-failure-models). +OpenDC provides three types of failure models: [Trace-based](#trace-based-failure-models), [Sample-based](#sample-based-failure-models), +and [Prefab](#prefab-failure-models). -All failure models have a similar structure containing three simple steps. +All failure models have a similar structure containing three simple steps. 1. The _interval_ time determines the time between two failures. 2. The _duration_ time determines how long a single failure takes. 3. The _intensity_ determines how many hosts are effected by a failure. -# Trace based failure models -Trace-based failure models are defined by a parquet file. This file defines the interval, duration, and intensity of +:::info Code +The code that defines the Failure Models can found [here](https://github.com/atlarge-research/opendc/blob/master/opendc-experiments/opendc-experiments-base/src/main/kotlin/org/opendc/experiments/base/experiment/specs/FailureModelSpec.kt). +::: + +## Trace based failure models +Trace-based failure models are defined by a parquet file. This file defines the interval, duration, and intensity of several failures. The failures defined in the file are looped. A valid failure model file follows the format defined below: | Metric | Datatype | Unit | Summary | @@ -17,7 +21,11 @@ several failures. The failures defined in the file are looped. A valid failure m | failure_duration | int64 | milli seconds | The duration of the failure | | failure_intensity | float64 | ratio | The ratio of hosts effected by the failure | -## Schema +:::info Code +The code implementation of Trace Based Failure Models can be found [here](https://github.com/atlarge-research/opendc/blob/master/opendc-compute/opendc-compute-failure/src/main/kotlin/org/opendc/compute/failure/models/TraceBasedFailureModel.kt) +::: + +### Example A trace-based failure model is specified by setting "type" to "trace-based". After, the user can define the path to the failure trace using "pathToFile": ```json @@ -36,17 +44,21 @@ The "repeat" value can be set to false if the user does not want the failures to } ``` -# Sample based failure models -Sample based failure models sample from three distributions to get the _interval_, _duration_, and _intensity_ of -each failure. Sample-based failure models are effected by randomness and will thus create different results based -on the provided seed. +## Sample based failure models +Sample based failure models sample from three distributions to get the _interval_, _duration_, and _intensity_ of +each failure. Sample-based failure models are effected by randomness and will thus create different results based +on the provided seed. + +:::info Code +The code implementation for the Sample based failure models can be found [here](https://github.com/atlarge-research/opendc/blob/master/opendc-compute/opendc-compute-failure/src/main/kotlin/org/opendc/compute/failure/models/SampleBasedFailureModel.kt) +::: -## Distributions +### Distributions OpenDC supports eight different distributions based on java's [RealDistributions](https://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/distribution/RealDistribution.html). Because the different distributions require different variables, they have to be specified with a specific "type". +Next, we show an example of a correct specification of all available distributions in OpenDC. #### [ConstantRealDistribution](https://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/distribution/ConstantRealDistribution.html) -A distribution that always returns the same value. ```json { @@ -71,7 +83,7 @@ A distribution that always returns the same value. "scale": 0.5 } ``` - + #### [LogNormalDistribution](https://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/distribution/LogNormalDistribution.html) ```json { @@ -93,7 +105,7 @@ A distribution that always returns the same value. #### [ParetoDistribution](https://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/distribution/ParetoDistribution.html) ```json { - "type": "constant", + "type": "pareto", "scale": 1.0, "shape": 0.6 } @@ -117,9 +129,9 @@ A distribution that always returns the same value. } ``` -## Schema +### Example A sample-based failure model is defined using three distributions for _intensity_, _duration_, and _intensity_. -Distributions can be mixed however the user wants. Note, values for _intensity_ and _duration_ are clamped to be positive. +Distributions can be mixed however the user wants. Note, values for _intensity_ and _duration_ are clamped to be positive. The _intensity_ is clamped to the range [0.0, 1.0). To specify a sample-based failure model, the type needs to be set to "custom". @@ -143,13 +155,13 @@ Example: } ``` -# Prefab failure models -The final type of failure models is the prefab models. These are models that are predefined in OpenDC and are based on -research. Currently, OpenDC has 9 prefab models based on [The Failure Trace Archive: Enabling the comparison of failure measurements and models of distributed systems](https://www-sciencedirect-com.vu-nl.idm.oclc.org/science/article/pii/S0743731513000634) +## Prefab failure models +The final type of failure models is the prefab models. These are models that are predefined in OpenDC and are based on +research. Currently, OpenDC has 9 prefab models based on [The Failure Trace Archive: Enabling the comparison of failure measurements and models of distributed systems](https://www-sciencedirect-com.vu-nl.idm.oclc.org/science/article/pii/S0743731513000634) The figure below shows the values used to define the failure models.  -Each failure model is defined four times, on for each of the four distribution. +Each failure model is defined four times, on for each of the four distribution. The final list of available prefabs is thus: G5k06Exp @@ -189,7 +201,11 @@ The final list of available prefabs is thus: Websites02LogN Websites02Gam -## Schema +:::info Code +The different Prefab models can be found [here](https://github.com/atlarge-research/opendc/tree/master/opendc-compute/opendc-compute-failure/src/main/kotlin/org/opendc/compute/failure/prefab) +::: + +### Example To specify a prefab model, the "type" needs to be set to "prefab". After, the prefab can be defined with "prefabName": diff --git a/site/docs/documentation/Input/Scenario.md b/site/docs/documentation/Input/Scenario.md deleted file mode 100644 index ff7b9ffb..00000000 --- a/site/docs/documentation/Input/Scenario.md +++ /dev/null @@ -1,125 +0,0 @@ -The scenario of a simulation is defined using a JSON file. A scenario consists of one or more topologies, one or more -workloads, one or more allocation policies, a name and a number of times the simulation is being run. - -## Schema - -The schema for the scenario file is provided in [schema](ScenarioSchema) -In the following section, we describe the different components of the schema. - -### General Structure - -| Variable | Type | Required? | Default | Description | -|----------------------|----------------------------------------------|-----------|-------|--------------------------------------------------------------------------| -| name | string | no | "" | Name of the scenario, used for identification and referencing. | -| topologies | List[[Topology](#topology)] | yes | N/A | List of topologies used in the scenario. | -| workloads | List[[Workload](#workload)] | yes | N/A | List of workloads to be executed within the scenario. | -| allocationPolicies | List[[AllocationPolicy](#allocation-policy)] | yes | N/A | Allocation policies used for resource management in the scenario. | -| failureModels | List[[FailureModel](#failuremodel)] | no | empty | List of failure models to simulate various types of failures. | -| exportModels | List[[ExportModel](#exportmodel)] | no | empty | Specifications for exporting data from the simulation. | -| carbonTracePaths | List[string] | no | null | Paths to carbon footprint trace files. | -| outputFolder | string | no | "output" | Directory where the simulation outputs will be stored. | -| initialSeed | integer | no | 0 | Seed used for random number generation to ensure reproducibility. | -| runs | integer | no | 1 | Number of times the scenario should be run. | - -### Topology - -| Variable | Type | Required? | Default | Description | -|-------------|--------|-----------|---------|---------------------------------------------------------------------| -| pathToFile | string | yes | N/A | Path to the JSON file defining the topology. | - -### Workload - -| Variable | Type | Required? | Default | Description | -|-------------|--------|-----------|---------|---------------------------------------------------------------------| -| pathToFile | string | yes | N/A | Path to the file containing the workload trace. | -| type | string | yes | N/A | Type of the workload (e.g., "ComputeWorkload"). | - -### Allocation Policy - -| Variable | Type | Required? | Default | Description | -|-------------|--------|-----------|---------|---------------------------------------------------------------------| -| policyType | string | yes | N/A | Type of allocation policy (e.g., "BestFit", "FirstFit"). | - -### FailureModel - -| Variable | Type | Required? | Default | Description | -|-------------|--------|-----------|---------|---------------------------------------------------------------------| -| modelType | string | yes | N/A | Type of failure model to simulate specific operational failures. | - -### ExportModel - -| Variable | Type | Required? | Default | Description | -|-------------|--------|-----------|---------|---------------------------------------------------------------------| -| exportType | string | yes | N/A | Specifies the type of data export model for simulation results. | - - -## Examples -In the following section, we discuss several examples of Scenario files. Any scenario file can be verified using the -JSON schema defined in [schema](TopologySchema). - -### Simple - -The simplest scneario that can be provided to OpenDC is shown below: -```json -{ - "topologies": [ - { - "pathToFile": "topologies/topology1.json" - } - ], - "workloads": [ - { - "pathToFile": "traces/bitbrains-small", - "type": "ComputeWorkload" - } - ], - "allocationPolicies": [ - { - "policyType": "Mem" - } - ] -} -``` - -This scenario creates a simulation from file topology1, located in the topologies folder, with a workload trace from the -bitbrains-small file, and an allocation policy of type Mem. The simulation is run once (by default), and the default -name is "". - -### Complex -Following is an example of a more complex topology: -```json -{ - "topologies": [ - { - "pathToFile": "topologies/topology1.json" - }, - { - "pathToFile": "topologies/topology2.json" - }, - { - "pathToFile": "topologies/topology3.json" - } - ], - "workloads": [ - { - "pathToFile": "traces/bitbrains-small", - "type": "ComputeWorkload" - }, - { - "pathToFile": "traces/bitbrains-large", - "type": "ComputeWorkload" - } - ], - "allocationPolicies": [ - { - "policyType": "Mem" - }, - { - "policyType": "Mem-Inv" - } - ] -} -``` - -This scenario runs a total of 12 experiments. We have 3 topologies (3 datacenter configurations), each simulated with -2 distinct workloads, each using a different allocation policy (either Mem or Mem-Inv). diff --git a/site/docs/documentation/Input/Topology.md b/site/docs/documentation/Input/Topology.md index cf726616..0d2479bd 100644 --- a/site/docs/documentation/Input/Topology.md +++ b/site/docs/documentation/Input/Topology.md @@ -2,6 +2,11 @@ The topology of a datacenter is defined using a JSON file. A topology consist of Each cluster consist of at least one host on which jobs can be executed. Each host consist of one or more CPUs, a memory unit and a power model. +:::info Code +The code related to reading and processing topology files can be found [here](https://github.com/atlarge-research/opendc/tree/master/opendc-compute/opendc-compute-topology/src/main/kotlin/org/opendc/compute/topology) +::: + + ## Schema The schema for the topology file is provided in [schema](TopologySchema). @@ -17,12 +22,12 @@ In the following section, we describe the different components of the schema. ### Host -| variable | type | required? | default | description | -|------------|-----------------------|-----------|---------|--------------------------------------------------------------------------------| -| name | string | no | Host | The name of the host. This is only important for debugging and post-processing | -| count | integer | no | 1 | The amount of hosts of this type are in the cluster | -| cpuModel | [CPU](#cpuModel) | yes | N/A | The CPUs in the host | -| memory | [Memory](#memory) | yes | N/A | The memory used by the host | +| variable | type | required? | default | description | +|-------------|-----------------------------|-----------|---------|--------------------------------------------------------------------------------| +| name | string | no | Host | The name of the host. This is only important for debugging and post-processing | +| count | integer | no | 1 | The amount of hosts of this type are in the cluster | +| cpuModel | [CPU](#cpu) | yes | N/A | The CPUs in the host | +| memory | [Memory](#memory) | yes | N/A | The memory used by the host | | power model | [Power Model](#power-model) | yes | N/A | The power model used to determine the power draw of the host | ### CPU @@ -49,12 +54,13 @@ In the following section, we describe the different components of the schema. ### Power Model -| variable | type | Unit | required? | default | description | -|-----------|---------|------|-----------|---------|----------------------------------------------------------------------------| -| modelType | string | N/A | yes | N/A | The type of model used to determine power draw | -| power | string | Watt | no | 400 | The constant power draw when using the 'constant' power model type in Watt | -| maxPower | string | Watt | yes | N/A | The power draw of a host when using max capacity in Watt | -| idlePower | integer | Watt | yes | N/A | The power draw of a host when idle in Watt | +| variable | type | Unit | required? | default | description | +|-----------------|--------|------|-----------|----------|-------------------------------------------------------------------------------| +| vendor | string | N/A | yes | N/A | The type of model used to determine power draw | +| modelName | string | N/A | yes | N/A | The type of model used to determine power draw | +| arch | string | N/A | yes | N/A | The type of model used to determine power draw | +| totalPower | Int64 | Watt | no | max long | The power draw of a host when using max capacity in Watt | +| carbonTracePath | string | N/A | no | null | Path to a carbon intensity trace. If not given, carbon intensity is always 0. | ## Examples @@ -71,12 +77,11 @@ The simplest data center that can be provided to OpenDC is shown below: { "hosts": [ { - "cpus": [ - { - "coreCount": 16, - "coreSpeed": 1000 - } - ], + "cpu": + { + "coreCount": 16, + "coreSpeed": 1000 + }, "memory": { "memorySize": 100000 } @@ -87,7 +92,7 @@ The simplest data center that can be provided to OpenDC is shown below: } ``` -This is creates a data center with a single cluster containing a single host. This host consist of a single 16 core CPU +This creates a data center with a single cluster containing a single host. This host consist of a single 16 core CPU with a speed of 1 Ghz, and 100 MiB RAM memory. ### Count @@ -102,14 +107,14 @@ Duplicating clusters, hosts, or CPUs is easy using the "count" keyword: "hosts": [ { "count": 5, - "cpus": [ - { - "coreCount": 16, - "coreSpeed": 1000, - "count": 10 - } - ], - "memory": { + "cpu": + { + "coreCount": 16, + "coreSpeed": 1000, + "count": 10 + }, + "memory": + { "memorySize": 100000 } } @@ -205,7 +210,7 @@ Aside from using number to indicate values it is also possible to define values "modelType": "linear", "power": "400 Watts", "maxPower": "1 KW", - "idlePower": "0.4W" + "idlePower": "0.4 W" } } ] diff --git a/site/docs/documentation/Input/Traces.md b/site/docs/documentation/Input/Traces.md deleted file mode 100644 index ec5782cb..00000000 --- a/site/docs/documentation/Input/Traces.md +++ /dev/null @@ -1,26 +0,0 @@ -### Traces -OpenDC works with two types of traces that describe the servers that need to be run. Both traces have to be provided as -parquet files. - -#### Meta -The meta trace provides an overview of the servers: - -| Metric | Datatype | Unit | Summary | -|--------------|------------|----------|--------------------------------------------------| -| id | string | | The id of the server | -| start_time | datetime64 | datetime | The submission time of the server | -| stop_time | datetime64 | datetime | The finish time of the submission | -| cpu_count | int32 | count | The number of CPUs required to run this server | -| cpu_capacity | float64 | MHz | The amount of CPU required to run this server | -| mem_capacity | int64 | MB | The amount of memory required to run this server | - -#### Trace -The Trace file provides information about the computational demand of each server over time: - -| Metric | Datatype | Unit | Summary | -|-----------|------------|---------------|---------------------------------------------| -| id | string | | The id of the server | -| timestamp | datetime64 | datetime | The timestamp of the sample | -| duration | int64 | milli seconds | The duration since the last sample | -| cpu_count | int32 | count | The number of cpus required | -| cpu_usage | float64 | MHz | The amount of computational power required. | diff --git a/site/docs/documentation/Input/Workload.md b/site/docs/documentation/Input/Workload.md new file mode 100644 index 00000000..5f2e61ae --- /dev/null +++ b/site/docs/documentation/Input/Workload.md @@ -0,0 +1,24 @@ +OpenDC works with two types of traces that describe the servers that need to be run. Both traces have to be provided as +parquet files. + +#### Task +The meta trace provides an overview of the servers: + +| Metric | Datatype | Unit | Summary | +|-----------------|----------|----------|--------------------------------------------------| +| id | string | | The id of the server | +| submission_time | int64 | datetime | The submission time of the server | +| duration | int64 | datetime | The finish time of the submission | +| cpu_count | int32 | count | The number of CPUs required to run this server | +| cpu_capacity | float64 | MHz | The amount of CPU required to run this server | +| mem_capacity | int64 | MB | The amount of memory required to run this server | + +#### Fragment +The Fragment file provides information about the computational demand of each server over time: + +| Metric | Datatype | Unit | Summary | +|-----------|------------|---------------|---------------------------------------------| +| id | string | | The id of the task | +| duration | int64 | milli seconds | The duration since the last sample | +| cpu_count | int32 | count | The number of cpus required | +| cpu_usage | float64 | MHz | The amount of computational power required. | |