Optimize che-server ram usage on Docker
Proposal is to set container limit to 750M for both Docker and OpenShift and tune a bit GC
-XX:MaxRAMFraction=2 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true -Xms20m
Important parts
-XX:MaxRAMFraction=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap - tels jvm to use ~ CHE_MASTER_CONTAINER_RAM/MaxRAMFraction for heap
We need some space for off-heap activity. During test I saw VmRSS of jvm ~330_000k - 350_000k.
-XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 ask GC to keep heap compact in cost of some CPU.
You can see changes in heap usage pattern in images below.
It contains the following changes:
Remove usage of outdated configuration parameters in deploy script
Move default values from yml files to deploy script
Put settings of common defaults to one section
Rename all properties in deploy script according to the Che format with using uppercase symbols and underscores
Remove usage of CHE_DEBUG_SERVER and CHE_KEYCLOAK_DISABLED
Fix default Che image that is used by deploy script
Remove unused labels and annotations
Move configuration properties from CHE_SERVER_CONFIGURATION env var to config map
Removed default properties extraction from war.
Removed all usage of CHE_LOCAL_CONF_DIR
Forced unset of CHE_LOCAL_CONF_DIR to make sure that Eclipse Che server can be configured only with environment variables.
Changed location of default properties from /codenvy/che.properties to /che/che.properties
Split deploy script into different areas:
- where defaults for each flavor are set
- where variables common to all flavors are set
(may depend on flavor dependent defaults)
- where Che deployment YAML file is customized with sed
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
Fix deployment to Minishift with the default behavior, in particular:
- increase timeout of waiting for Postgres start
- remove the second check of Postgres after the first one (didn't get why there were 2 of them)
- fix bugs in checking for Postgres status
- fix TLS configuration for Minishift
- renamed deployment configuration
Signed-off-by: Oleksandr Garagatyi <ogaragat@redhat.com>
* Ping the wsagent URL (possibly external), not the *internal URL*.
* Use `getProperties().getInternalUrl()` when `getUrl()` returns `null`
* Add a new provider for an optional routing suffix for workspaces to be
used in the external URLs of created workspace agents in the
use-cases where a custom server evaluation strategy is used (Openshift,
Traeffik, etc ...).
* Add 2 new macros for the custom server evaluation template which are:
- `user`: the current environment context user if any,
- `workspacesRoutingSuffix`: the suffix returned by the available
`WorspacesRoutingSuffixProvider` if any.
Both values can null, in which case they are not added to the ST
variables, so that it is possible to test on their existence in the
template. For example:
```
<if(workspacesRoutingSuffix)><user>-che.<workspacesRoutingSuffix><else><externalAddress><endif>
```
* Add a new provider to get workspace-related Openshift configuration containing:
- the `io.fabric8.kubernetes.client.Config` object to connect the right
Openshift cluster / namespace in which workspaces will be created
- The name of the namespace in which workspaces are cteated
- A boolean that tell if the workspaces will be created in a different
cluster as the che-server.
These data returned by the subclasses of the new provider can of course
depend on the current user (and this will be the case for multi-tenancy)
* Also support the `application/vnd.api+json` content type in responses
* Now use the new providers to connect to the right clutser / namespace
* Allow the Docker connector to return the API endpoint...
The base `DockerConnector` class returns `null` as the endpoint, thus
keeping the previous behavior.
However the `OpenshiftConnector` implementation now returns the API
endpoint without the need for any environment variable:
Indeed in the case of Openshift, the API endpoint is either based on:
- the internal fully-qualified name of the `che-host` service if
workspaces are to be hosted on the same Openshift cluster,
- the external URL of the `che` route if workspaces may be hosted on a
distinct Openshift cluster.
* If related properties or env variables are void, use the connector to retrieve
the API endpoint.
* Required changes for multi-tenancy in deployment script
* Allow overriding the agent log directories in a clean way so that we don't need
to replace the `XXXWsMasterModule` class only
to override the `run_command` binding.
* Move some local-docker-related configuration into a separate `dynamodule`.
This avoid the need to override the `WsMasterModule` class and comment
these bindings in derived assemblies that use a distinct implementation
or don't need Traeffik (such as for Openshift deployments).
* Return `OpenShiftException` when workspaces namespace cannot be reached
* Add multi-tenancy options to the deploy script
* Add the `CHE_EPHEMERAL` and `CHE_USE_ACME_CERTIFICATE` options
* Fix the name of the used docker image for multi-tenant
Signed-off-by: David Festal <dfestal@redhat.com>
Eugene Ivantsov