Chapter 2. Calculating CodeReady Workspaces resource requirements
This section describes how to calculate resources (memory and CPU) required to run Red Hat CodeReady Workspaces.
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.
2.1. 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.
Pod | Container name | Default memory limit | Default memory request |
---|---|---|---|
CodeReady Workspaces Server and Dashboard | che | 1 GiB | 512 MiB |
PostgreSQL | postgres | 1 GiB | 512 MiB |
RH-SSO | 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 https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/installation_guide/index#advanced-configuration-options-for-the-codeready-workspaces-server-component_crw article for instructions on how to override the default requests and limits. For example, the hosted version of CodeReady Workspaces that runs on https://che.openshift.io uses 1 GB of memory.
2.2. 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
-
Identify the workspace components explicitly specified in the
components
section of the https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw. Identify the implicit workspace components:
-
CodeReady Workspaces implicitly loads the default
cheEditor
:che-theia
, and thechePlugin
that allows commands execution:che-machine-exec-plugin
. To change the default editor, add acheEditor
component section in the devfile. -
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.
-
CodeReady Workspaces implicitly loads the default
Calculate the requirements for each component:
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 2.2. Default requirements of workspace components by type Component types CodeReady Workspaces server property Default memory limit Default 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
Custom requirements for
chePlugins
andcheEditors
components:Custom memory limit and request:
If present, the
memoryLimit
andmemoryRequest
attributes of thecontainers
section of themeta.yaml
file define the memory limit of thechePlugins
orcheEditors
components. CodeReady Workspaces automatically sets the memory request to match the memory limit in case it is not specified explicitly.Example 2.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
TipHow to find the
meta.yaml
file ofchePlugin
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
ishttp://plugin-registry-che.192.168.64.78.nip.io/v3/plugins/che-incubator/typescript/latest/meta.yaml
.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
andcheEditor
types in themeta.yaml
file or in the devfile in the same way as it done for memory limits.Example 2.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:
|
|
|
|
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.
Custom requirements for
dockerimage
componentsIf present, the
memoryLimit
andmemoryRequest
attributes of the devfile define the memory limit of adockerimage
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
Custom requirements for
kubernetes
oropenshift
components:The referenced manifest may define the memory requirements and limits.
- Add all requirements previously calculated.
2.3. 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:
Pod | Container name | Default memory limit | Default memory request |
---|---|---|---|
Workspace |
theia-ide (default | 512 MiB | 512 MiB |
Workspace |
machine-exec (default | 128 MiB | 128 MiB |
Workspace |
vscode-typescript ( | 512 MiB | 512 MiB |
Workspace |
frontend ( | 1 GiB | 512 MiB |
JWT Proxy | verifier | 128 MiB | 128 MiB |
Total | 2.25 GiB | 1.75 GiB |
-
The
theia-ide
andmachine-exec
components are implicitly added to the workspace, even when not included in the devfile. -
The resources required by
machine-exec
are the default forchePlugin
. -
The resources for
theia-ide
are specifically set in thecheEditor
meta.yaml
to 512 MiB asmemoryLimit
. -
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 thekubernetes
component references aDeployment
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.
Additional resources
- Chapter 1, CodeReady Workspaces architecture overview
- Kubernetes compute resources management documentation
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/installation_guide/index#configuring-the-codeready-workspaces-installation_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/installation_guide/index#advanced-configuration-options-for-the-codeready-workspaces-server-component_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.4/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw#a-minimal-devfile_crw
- Section 8.1, “Authenticating users”
- che-plugin-registry GitHub repository