Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 130: Ability to specify container resources #129

Merged
merged 19 commits into from
Mar 22, 2019
Merged

Conversation

adrianmo
Copy link
Contributor

@adrianmo adrianmo commented Mar 4, 2019

Change log description

This PR will bring the following changes:

At this moment, the PR is being used for testing with the goal of finding the suitable values for resource requests and limits.

Purpose of the change

Fix #130

How to test the change

When defining the Pravega cluster specification in the YAML file, include the following options to set custom resource requests and limits for each Pravega component.

apiVersion: "pravega.pravega.io/v1alpha1"
kind: "PravegaCluster"
metadata:
  name: "example"
spec:
  ...
  bookkeeper:
    ...
    resources:
      requests:
        memory: "3Gi"
        cpu: "1000m"
      limits:
        memory: "5Gi"
        cpu: "2000m"

  pravega:
    ...
    controllerResources:
      requests:
        memory: "1Gi"
        cpu: "1000m"
      limits:
        memory: "3Gi"
        cpu: "2000m"

    segmentStoreResources:
      requests:
        memory: "3Gi"
        cpu: "1000m"
      limits:
        memory: "5Gi"
        cpu: "2000m"

You can verify that those values have been correctly set by looking at the Pods description.


Signed-off-by: Adrián Moreno adrian@morenomartinez.com

Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
@adrianmo adrianmo changed the title [WiP] Ability to specify container resources [WiP] Issue 130: Ability to specify container resources Mar 4, 2019
adrianmo and others added 9 commits March 13, 2019 12:51
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
* master:
  Issue 134,137: Fix BookKeeper errors (#135)
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
@adrianmo adrianmo changed the title [WiP] Issue 130: Ability to specify container resources Issue 130: Ability to specify container resources Mar 20, 2019
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
Copy link

@RaulGracia RaulGracia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, some comments.

changed = true
s.Resources = &v1.ResourceRequirements{
Requests: v1.ResourceList{
v1.ResourceCPU: resource.MustParse("500m"),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why these values are lower than the ones in cr-detailed.yaml? Shall we stick to a consistent defaults?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default values are meant to represent the bare minimum requirements for Pravega to run. These values are intended to be use in a first contact with Pravega, functional testing, or development work. Therefore, we want to keep them low so that Pravega can be deployed to small Kubernetes clusters. Whereas the values in cr-detailed.yaml are just an example of how the default resources would be overridden to tune Pravega resources to a higher performance cluster.

changed = true
s.ControllerResources = &v1.ResourceRequirements{
Requests: v1.ResourceList{
v1.ResourceCPU: resource.MustParse("250m"),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here with the defaults compared to cr-detailed.yaml.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Responded in #129 (comment)

javaOpts := []string{
"-Xms1g -Xmx4g -XX:MaxDirectMemorySize=1g -Dpravegaservice.clusterName=" + pravegaCluster.Name,
"-Xms1g",
"-XX:+UnlockExperimentalVMOptions",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these options configurable as part of another PR, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, JVM options are not externally configurable.

Copy link

@RaulGracia RaulGracia Mar 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this may not be great, because we will rely on the default -Xmx value set by the JVM implementation. The default may be set as follows:

Often its default value is 1/4th of your physical memory or 1GB (whichever is smaller).

So, we may end up providing 4GBs of memory to a pod, but 1GB at most will be devoted to the JVM (despite the main purpose of that pod is to run the JVM for the Pravega process at hand). What is your opinion about this? Have you used -XX:+PrintFlagsFinal to see what is the actual -Xmx value that is being used? Would it make sense to set the -Xmx value in function to the provisioned memory resources for the pod?

@@ -12,6 +12,13 @@ spec:
pullPolicy: IfNotPresent

replicas: 3
resources:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any test that validates that these values are properly passed to the process?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we will work on adding a test to validate that resources are passed down to pod templates correctly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test added. Could you please review it again? Thanks!

wenqi added 2 commits March 20, 2019 17:04
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
@adrianmo adrianmo added the status/ready The issue is ready to be worked on; or the PR is ready to review label Mar 21, 2019
Copy link
Contributor Author

@adrianmo adrianmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tristan1900 awesome work adding the test cases. Thanks!

Copy link

@RaulGracia RaulGracia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have one comment that may be relevant for JVM provisioning.

javaOpts := []string{
"-Xms1g -Xmx4g -XX:MaxDirectMemorySize=1g -Dpravegaservice.clusterName=" + pravegaCluster.Name,
"-Xms1g",
"-XX:+UnlockExperimentalVMOptions",
Copy link

@RaulGracia RaulGracia Mar 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this may not be great, because we will rely on the default -Xmx value set by the JVM implementation. The default may be set as follows:

Often its default value is 1/4th of your physical memory or 1GB (whichever is smaller).

So, we may end up providing 4GBs of memory to a pod, but 1GB at most will be devoted to the JVM (despite the main purpose of that pod is to run the JVM for the Pravega process at hand). What is your opinion about this? Have you used -XX:+PrintFlagsFinal to see what is the actual -Xmx value that is being used? Would it make sense to set the -Xmx value in function to the provisioned memory resources for the pod?

@adrianmo
Copy link
Contributor Author

adrianmo commented Mar 21, 2019

Would it make sense to set the -Xmx value in function to the provisioned memory resources for the pod?

@RaulGracia that's exactly what -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap flags do. These flags were introduced in Java 8u131 and Java 9 and, when they are set and -Xmx is not set, JVM heap size will be set according to the cgroup configuration, which is what we specify in the Pod resource limit. Source: https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits

Copy link

@RaulGracia RaulGracia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Signed-off-by: wenqi <Wenqi.Mou@emc.com>
wenqi and others added 2 commits March 21, 2019 21:53
Signed-off-by: wenqi <Wenqi.Mou@emc.com>
Signed-off-by: Adrián Moreno <adrian@morenomartinez.com>
@adrianmo adrianmo merged commit 78d9944 into master Mar 22, 2019
@adrianmo adrianmo deleted the set-pod-resources branch March 22, 2019 14:18
adrianmo added a commit that referenced this pull request Mar 29, 2019
* master:
  Issue 130: Ability to specify container resources (#129)
  Issue 134,137: Fix BookKeeper errors (#135)
  Run tests on GKE (#140)
  Document update: README.md (#133)
  Add service account role definitions [skip ci] (#136)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/ready The issue is ready to be worked on; or the PR is ready to review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants