Tuning and controlling memory usage

Note

It is strongly recommended that you get familiar with the different kind of processes in DSS to understand this section. See Understanding and tracking DSS processes for more information

The backend

The backend is a Java process that has a fixed memory allocation set by the backend.xmx ini parameter.

It is recommended to allocate ample Java memory to the backend. Backend memory requirement scales with:

  • The number of users
  • The number of projects, datasets, recipes, …
  • Overall activity (automatically running scenarios, use of data preparation design)

For large production instances, we recommend allocating 12 to 20 GB of memory for the backend.

If the memory allocation is insufficient, the DSS backend may crash. This will result in the “Disconnected” overlay appearing for all users and running jobs/scenarios to be aborted. The backend restarts automatically after a few seconds.

Setting the backend Xmx

In this example, we are setting the backend Xmx to 12g

  • Go to the DSS data directory

Note

On macOS, the DATA_DIR is always: $HOME/Library/DataScienceStudio/dss_home

  • Stop DSS

    ./bin/dss stop

  • Edit the install.ini file

  • If it does not exist, add a [javaopts] section

  • Add a line: backend.xmx = 12g

  • Regenerate the runtime config:

    ./bin/dssadmin regenerate-config

  • Start DSS

    ./bin/dss start

For more details on how to tune Java processes settings, see Java runtime environment.

The JEK

The default Xmx of the JEK is 2g. This is enough for a large majority of jobs. However, some jobs with large number of partitions or large number of files to process may require more. This is configured by the jek.xmx ini parameter.

Note that:

  • The jek.xmx setting is global, and cannot be set per-job, per-user or per-project
  • This memory allocation will be multiplied by the number of JEK (see Understanding and tracking DSS processes for more details), so don’t put a huge amount for jek.xmx as it will also be multiplied.

If you see JEK crashes due to memory errors, we recommend that you increase progressively. For example, first to 3g then to 4g.

Setting the JEK Xmx

In this example, we are setting the JEK Xmx to 3g

  • Go to the DSS data directory

Note

On macOS, the DATA_DIR is always: $HOME/Library/DataScienceStudio/dss_home

  • Stop DSS

    ./bin/dss stop

  • Edit the install.ini file

  • If it does not exist, add a [javaopts] section

  • Add a line: jek.xmx = 3g

  • Regenerate the runtime config:

    ./bin/dssadmin regenerate-config

  • Start DSS

    ./bin/dss start

For more details on how to tune Java processes settings, see Java runtime environment.

Investigate if a crash is related to memory

If you experience job crashes without error messages and want to know if it’s related to lack of JEK memory:

  • Open the “Full job log” from the Actions menu of the job page
  • Scroll to the end of the log.
  • You’ll see the logs of the crash. If you see “OutOfMemoryError: Java heap space” or “OutOfMemoryError: GC Overhead limit exceeded”, then you need to increase jek.xmx

The FEKs

The default Xmx of each FEK is 2g. This is enough for a large majority of tasks. There may be some rare cases where you’ll need to allocate more memorry (generally at the direction of Dataiku Support). This is configured by the fek.xmx ini parameter.

Note that:

  • The fek.xmx setting is global, and cannot be set per-user or per-project
  • This memory allocation will be multiplied by the number of FEK (see Understanding and tracking DSS processes for more details), so don’t put a huge amount for fek.xmx as it will also be multiplied.

Setting the FEK Xmx

In this example, we are setting the FEK Xmx to 3g

  • Go to the DSS data directory

Note

On macOS, the DATA_DIR is always: $HOME/Library/DataScienceStudio/dss_home

  • Stop DSS

    ./bin/dss stop

  • Edit the install.ini file

  • If it does not exist, add a [javaopts] section

  • Add a line: fek.xmx = 3g

  • Regenerate the runtime config:

    ./bin/dssadmin regenerate-config

  • Start DSS

    ./bin/dss start

For more details on how to tune Java processes settings, see Java runtime environment.

Jupyter notebook kernels

Memory allocation for Jupyter notebooks can be controlled using the cgroups integration

Python and R recipes

Memory allocation for Python annd R recipes can be controlled using the cgroups integration

Note

This does not apply if you used containerized execution for this recipe. See containerized execution documentation for more information about processes and controlling memory usage for containers

SparkSQL and visual recipes with Spark engine

These recipes are made of a large number of processes:

  • The Spark driver, a Java process that runs locally
  • The Spark executors, Java processes that run in your cluster (usually through YARN)

Memory for both can be controlled using the usual Spark properties (spark.driver.memory and spark.executory.memory) which can be set in Spark named configurations

PySpark, SparkR and sparklyr recipes

The case of these recipes is a bit particular, because they are actually made of several processes:

  • A Python or R process which runs your driver code
  • The Spark driver, a Java process that runs locally
  • The Spark executors, Java processes that run in your cluster (usually through YARN)

Memory for the Spark driver and executors can be controlled using the usual Spark properties (spark.driver.memory and spark.executory.memory) which can be set in Spark named configurations

Memory for the local Python or R process can be controlled using the cgroups integration

In-memory machine learning

Memory allocation for in-memory machine learning processes can be controlled using the cgroups integration

Note

This does not apply if you used containerized execution for this recipe. See containerized execution documentation for more information about processes and controlling memory usage for containers

Webapps

Memory allocation for webapps can be controlled using the cgroups integration