Chapter 8. Calculating CodeReady Workspaces resource requirements

This section describes how to calculate resources (memory and CPU) required to run Red Hat CodeReady Workspaces.

8.1. CodeReady Workspaces architectural components

As illustrated in the High-level CodeReady Workspaces architecture article, Red Hat CodeReady Workspaces components are:

  • A central workspace controller: an always running service that manages users workspaces
  • Users workspaces: container-based IDEs that the controller stops when the user stops coding.
crw high level

Both the CodeReady Workspaces central controller and user workspaces consist of a set of containers. Those containers contribute to the resources consumption in terms of CPU and RAM limits and requests. For a detailed explanation of how OpenShift manages container-resource requests and limits, see OpenShift documentation.

8.2. Controller requirements

The Workspace Controller consists of a set of five services running in five distinct containers. The following table presents the default resource requirements of each of these services.

Table 8.1. ControllerServices

PodContainer nameDefault memory limitDefault memory request

CodeReady Workspaces Server and Dashboard

che

1 GiB

512 MiB

PostgreSQL

postgres

1 GiB

512 MiB

Red Hat Single Sign-On

keycloak

2 GiB

512 MiB

Devfile registry

che-devfile-registry

256 MiB

16 MiB

Plug-in registry

che-plugin-registry

256 MiB

16 MiB

These default values are sufficient when the CodeReady Workspaces Workspace Controller manages a small amount of CodeReady Workspaces workspaces. For larger deployments, increase the memory limit. See the Advanced configurations options article for instructions on how to override the default requests and limits. For example, the hosted version of CodeReady Workspaces that runs on che.openshift.io uses 4 GiB of memory.

8.3. Workspaces requirements

This section describes how to calculate the resources required for a workspace. It is the sum of the resources required for each component of this workspace.

These examples demonstrate the necessity of a proper calculation:

  • A workspace with 10 active plug-ins requires more resources then the same workspace with fewer plug-ins.
  • A standard Java workspace requires more resources than a standard Node.js workspace because running builds, tests, and application debugging requires more resources.

Procedure

  1. Identify the workspace components explicitly specified in the components section of the devfile.
  2. Identify the implicit workspace components:

    1. CodeReady Workspaces implicitly loads the default cheEditor: che-theia, and the chePlugin that allows commands execution: che-machine-exec-plugin. To change the default editor, add a cheEditor component section in the devfile.
    2. When CodeReady Workspaces is running in multiuser mode, it loads the JWT Proxy component. The JWT Proxy is responsible for the authentication and authorization of the external communications of the workspace components.
  3. Calculate the requirements for each component:

    1. Default values:

      The following table presents the default requirements for all workspace components. It also presents the corresponding CodeReady Workspaces server property to modify the defaults cluster-wide.

      Table 8.2. Default requirements of workspace components by type

      Component typesCodeReady Workspaces server propertyDefault memory limitDefault memory request

      chePlugin

      che.workspace.sidecar.default_memory_limit_mb

      128 MiB

      128 MiB

      cheEditor

      che.workspace.sidecar.default_memory_limit_mb

      128 MiB

      128 MiB

      kubernetes, openshift, dockerimage

      che.workspace.default_memory_limit_mb, che.workspace.default_memory_request_mb

      1 Gi

      512 MiB

      JWT Proxy

      che.server.secure_exposer.jwtproxy.memory_limit

      128 MiB

      128 MiB

    2. Custom requirements for chePlugins and cheEditors components:

      1. Custom memory limit and request:

        If present, the memoryLimit and memoryRequest attributes of the containers section of the meta.yaml file define the memory limit of the chePlugins or cheEditors components. CodeReady Workspaces automatically sets the memory request to match the memory limit in case it is not specified explicitly.

        Example 8.1. The chePlugin che-incubator/typescript/latest

        meta.yaml spec section:

        spec:
         containers:
           - image: docker.io/eclipse/che-remote-plugin-node:next
             name: vscode-typescript
             memoryLimit: 512Mi
             memoryRequest: 256Mi

        It results in a container with the following memory limit and request:

        Memory limit

        512 MiB

        Memory request

        256 MiB

        Tip

        How to find the meta.yaml file of chePlugin

        Community plug-ins are available in the che-plugin-registry GitHub repository in folder v3/plugins/${organization}/${name}/${version}/.

        For non-community or customized plug-ins, the meta.yaml files are available on the local OpenShift cluster at ${pluginRegistryEndpoint}/v3/plugins/${organization}/${name}/${version}/meta.yaml.

        For example, on a local Minikube cluster, the URL for the che-incubator/typescript/latest meta.yaml is http://plugin-registry-che.192.168.64.78.mycluster.mycompany.com/v3/plugins/che-incubator/typescript/latest/meta.yaml.

      2. Custom CPU limit and request:

        CodeReady Workspaces does not set CPU limits and requests by default. However, it is possible to configure CPU limits for the chePlugin and cheEditor types in the meta.yaml file or in the devfile in the same way as it done for memory limits.

        Example 8.2. The chePlugin che-incubator/typescript/latest

        meta.yaml spec section:

        spec:
         containers:
           - image: docker.io/eclipse/che-remote-plugin-node:next
             name: vscode-typescript
             cpuLimit: 2000m
             cpuRequest: 500m

        It results in a container with the following CPU limit and request:

        CPU limit

        2 cores

        CPU request

        0.5 cores

To set CPU limits and requests globally, use the following dedicated environment variables:

CPU Limit

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__LIMIT__CORES

CPU Request

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__REQUEST__CORES

See also Advanced configuration options for the CodeReady Workspaces server component.

Note that the LimitRange object of the OpenShift project may specify defaults for CPU limits and requests set by cluster administrators. To prevent start errors due to resources overrun, limits on application or workspace levels must comply with those settings.

  1. Custom requirements for dockerimage components

    If present, the memoryLimit and memoryRequest attributes of the devfile define the memory limit of a dockerimage container. CodeReady Workspaces automatically sets the memory request to match the memory limit in case it is not specified explicitly.

      - alias: maven
        type: dockerimage
        image: eclipse/maven-jdk8:latest
        memoryLimit: 1536M
  2. Custom requirements for kubernetes or openshift components:

    The referenced manifest may define the memory requirements and limits.

    1. Add all requirements previously calculated.

8.4. A workspace example

This section describes a CodeReady Workspaces workspace example.

The following devfile defines the CodeReady Workspaces workspace:

apiVersion: 1.0.0
metadata:
 generateName: guestbook-nodejs-sample-
projects:
 - name: guestbook-nodejs-sample
   source:
     type: git
     location: "https://github.com/l0rd/nodejs-sample"
components:
 - type: chePlugin
   id: che-incubator/typescript/latest
 - type: kubernetes
   alias: guestbook-frontend
   reference: https://raw.githubusercontent.com/l0rd/nodejs-sample/master/kubernetes-manifests/guestbook-frontend.deployment.yaml
   mountSources: true
   entrypoints:
     - command: ['sleep']
       args: ['infinity']

This table provides the memory requirements for each workspace component:

Table 8.3. Total workspace memory requirement and limit

PodContainer nameDefault memory limitDefault memory request

Workspace

theia-ide (default cheEditor)

512 MiB

512 MiB

Workspace

machine-exec (default chePlugin)

128 MiB

128 MiB

Workspace

vscode-typescript (chePlugin)

512 MiB

512 MiB

Workspace

frontend (kubernetes)

1 GiB

512 MiB

JWT Proxy

verifier

128 MiB

128 MiB

Total

2.25 GiB

1.75 GiB

  • The theia-ide and machine-exec components are implicitly added to the workspace, even when not included in the devfile.
  • The resources required by machine-exec are the default for chePlugin.
  • The resources for theia-ide are specifically set in the cheEditor meta.yaml to 512 MiB as memoryLimit.
  • The Typescript VS Code extension has also overridden the default memory limits. In its meta.yaml file, the limits are explicitly specified to 512 MiB.
  • CodeReady Workspaces is applying the defaults for the kubernetes component type: a memory limit of 1 GiB and a memory request of 512 MiB. This is because the kubernetes component references a Deployment manifest that has a container specification with no resource limits or requests.
  • The JWT container requires 128 MiB of memory.

Adding all together results in 1.75 GiB of memory requests with a 2.25 GiB limit.

8.5. Additional resources