Add JAVA_OPTS to helm chart #995
Conversation
abielawa
commented
Dec 6, 2022
abielawa
commented
- Added JAVA_OPTS to bootzooka helm chart
helm/bootzooka/values.yaml
Outdated
| @@ -38,6 +38,7 @@ bootzooka: | |||
| username: "server.example.com" | |||
| from: "[email protected]" | |||
| password: "bootzooka" | |||
| javaOpts: "-XX:ActiveProcessorCount=2 -XX:MaxRAMPercentage=60" | |||
There was a problem hiding this comment.
shouldn't the processor count be determined from the allocated resources?
There was a problem hiding this comment.
In kubernetes, while specifying the cpu request: 100m and the limit: 1000m the JVM pod will always see only 1 core. By combining resources requests/limits with -XX:ActiveProcessorCount=2 we can keep the requests/limits lower and make the pod see 2 cores to prevent cpu throttling.
There was a problem hiding this comment.
is this request/limit configuraton somehow centrlised? I can't see it in this file.
And why 2, not 4? Is there some formula to calculate this?
There was a problem hiding this comment.
The default values for resource request/limits are not defined in Helm Chart - we overwrite them in Flux configuration in another repository where we have all the apps for the infrastructure defined.
Also, the javaOpts will be overwritten in the same way - probably won't ever be used since we always overwrite those values - but has to be defined just in case someone forgets to set them later.
From now on, for each deployment the javaOpts and resource request/limits have to be configured according to the requirements.
There was a problem hiding this comment.
shouldn't we define default requests/limits here as well, then?
and why 2, not 4? ;)
There was a problem hiding this comment.
At this point, in this repo you don't know where the app will be deployed - whether it will be the test, dev or prod environment and how many resources your app can use in this specific environment - so requests/limits by default are unnecessary because they are connected to the resources of the environment itself.
So the 2 was the minimal possible value that could be applied to take effect. The main reason I specified the default value was that I thought it could be overwritten by any value.
But after giving some thought and doing research I found out that the ActiveProccessorAccount has higher priority than request/limits, for example even if we specify the cpu limit: 4 and ActiveProccessorAccount=2, the cpu would be 2 because of the ActiveProccessorAccount=2. So it’s not safe to specify the default value and also we don’t know the environment similarly as for requests/limits - I will remove the ActiveProccessorAccount from the defaults.
|
Do we know why the tests fail? |
Afaik bootzooka Helm chart has a version constraint dependency for Postgres Helm chart from Bitnami. But version 9 is no longer supported by Bitnami. |
|
Ok, can we fix this separately as well? |
I will fix this before releasing the Helm chart |
|
Thanks:) |
