Configuring runtime environments

The system supports changing the default runtime values, such as the allocated memory or CPUs. This is useful if you want to ingest large amounts of data and improve application performance.

You can configure the runtime of the following components:

  • Database
  • Deployment
  • Grafana
  • HAProxy
  • Liberty
  • Prometheus
  • Solr
  • ZooKeeper
  • Connector Designer

Creating environment runtime files

The /runtime-environments directory is used to contain the .properties files that define the available runtime environments. The name of the .properties file specifies the name for the runtime environment. The file name is formed as runtime-<environment_name>.properties.

For example:

  • runtime-default.properties
  • runtime-dev.properties
  • runtime-large.properties

Important: If there is a runtime-default.properties file then it is used as the default environment runtime when a config is deployed.

Specifying the runtime values

The allowed settings in the runtime properties files conforms to the following convention:

<component>.<option_name>

Where:

  • <component> is the name of one of the components i2 Analyze consists of. For example solr.
    The available components are:

    • db
    • deployment
    • grafana
    • haproxy
    • liberty
    • prometheus
    • solr
    • zookeeper
    • connector-designer

  • <option_name> is the name of the option. This name is passed directly to Docker. The name must match the name of the option as described in the Docker documentation. For example the Docker run option --memory becomes memory. The exception to this rule is for the deployment component, where the options are passed to i2 Analyze directly.

The most common runtime options that you might want to configure include:

  • memory - The maximum amount of memory the container can use. If you set this option, the minimum allowed value is 6m (6 megabytes). For more information, see Docker run - memory.
  • memory-swap - Memory swap limit which equals to memory plus swap or '-1' to enable unlimited swap. For more information, see Docker run - memory swap
  • cpus - Number of CPUs. Number can be a fractional number. 0.000 means no limit. For more information, see Docker run - cpu
  • display-name-suffix - The deployment display name suffix. The value is appended to the deployment name set in the configuration. For more information about the deployment name, see Setting a deployment name

For example, you might create a runtime-dev.properties file and populate the settings as:

solr.memory=6g
solr.memory-swap=1g
solr.cpus=4

liberty.memory=4g

zookeeper.memory=2g

db.memory=4g

deployment.display-name-suffix=dev

Deploying a config with a specific runtime environment

To deploy a config with a specific runtime, run:

deploy -e <runtime_environment>

Where <runtime_environment> is dev for settings in /runtime-environments/runtime-dev.properties file.
If you have multiple configs, specify the config name with -c <config-name>.

Using local variables

You can use local variables to override the runtime properties individually. When you run the deploy command with the local variables specified, these values are used instead of the values for the matching options in a runtime environment properties file.

The naming convention for these variables is:

RUNTIME_<component>_<option_name>

The mapping of the <option_name> is similar to the one used in the .properties file where the names used are the same. The only difference is that if <option_name> has a hyphen (-) it must be replaced by an underscore (_).

To specify the local variables to be used, create a docker.env file in the analyze-deployment-tooling directory.

To populate the file with the same settings as above, use the following variables and values:

RUNTIME_SOLR_MEMORY="6g"
RUNTIME_SOLR_MEMORY_SWAP="1g"
RUNTIME_SOLR_CPUS="4"

RUNTIME_LIBERTY_MEMORY="4g"

RUNTIME_DB_MEMORY="4g"

RUNTIME_ZOOKEEPER_MEMORY="4g"

RUNTIME_DEPLOYMENT_DISPLAY_NAME_SUFFIX="dev"

You can also use a local variable to override the runtime environment properties file that is used. To do this, use the RUNTIME_ENVIRONMENT variable in the docker.env file.

In the file, use the RUNTIME_ENVIRONMENT variable to reference the name of a runtime environment properties file, for example:

RUNTIME_ENVIRONMENT=dev