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

[Feature Request]: adjust cpu and memory request and limit sizes in manifests #1786

Open
shalberd opened this issue Sep 14, 2023 · 1 comment
Labels
community infrastructure Anything non feature/* related that improves general working of the Dashboard kind/enhancement New functionality request (existing augments or new additions) needs-info Further information is requested from the reporter or from another source priority/normal An issue with the product; fix when possible

Comments

@shalberd
Copy link
Contributor

shalberd commented Sep 14, 2023

Feature description

Currently, cpu and memory resource settings for odh dashboard are in no way representative of real usage.

https://github.com/opendatahub-io/odh-dashboard/blob/main/manifests/base/deployment.yaml#L34

https://github.com/opendatahub-io/odh-dashboard/blob/main/manifests/base/deployment.yaml#L104

Bildschirmfoto 2023-09-14 um 12 55 41

Bildschirmfoto 2023-09-14 um 13 01 06

Bildschirmfoto 2023-09-14 um 13 01 34

Let's start with CPU:

there is no reason for the pod to only be scheduled if 0.5 CPU is free on any worker node.
A request of 200m would be more than enough. Keep in mind: We've got two pods of odh-dashboard running, which means in case we change this setting, there is already 0.3 * 2 = 0.6 CPU Cores available for scheduling other containers and pods on the node.

Average usage in my experience never even exceeded 200m, so the limit can be set to let's say 250m, just in case.

Regarding memory:

We have a relatively simple Web app here ... average memory usage in my monitoring never exceeded 350Mi.

So, I'd say requests.memory should be changed from 1Gi to 350Mi and
limits.memory should be changed from 2Gi to 400Mi.

Using these settings, in terms of QoS, we allow for some bursting, while not over-reserving (requests) too much initially.

What do you think?

Thank you, @tkolo for pointing me to this. #1730 (comment)

to summarize, I'd propose changing the deployment.yaml section to the following for odh-dashboard

        resources:
          limits:
            cpu: 300m
            memory: 350Mi
          requests:
            cpu: 200m
            memory: 250Mi

and for oauth-proxy:

        resources:
          limits:
            cpu: 100m
            memory: 120Mi
          requests:
            cpu: 50m
            memory: 100Mi

Describe alternatives you've considered

No response

Anything else?

No response

@shalberd shalberd added kind/enhancement New functionality request (existing augments or new additions) priority/normal An issue with the product; fix when possible untriaged Indicates the newly create issue has not been triaged yet labels Sep 14, 2023
@github-project-automation github-project-automation bot moved this to Needs prioritization in ODH Dashboard Planning Sep 14, 2023
@alexcreasy alexcreasy added needs-info Further information is requested from the reporter or from another source and removed untriaged Indicates the newly create issue has not been triaged yet labels Sep 19, 2023
@alexcreasy alexcreasy moved this from Untriaged to Dev To do in ODH Dashboard Planning Sep 19, 2023
@alexcreasy alexcreasy added the infrastructure Anything non feature/* related that improves general working of the Dashboard label Sep 19, 2023
@shalberd
Copy link
Contributor Author

tested on our cluster and working well for us, with about 5-10 dashboard users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community infrastructure Anything non feature/* related that improves general working of the Dashboard kind/enhancement New functionality request (existing augments or new additions) needs-info Further information is requested from the reporter or from another source priority/normal An issue with the product; fix when possible
Projects
Status: No status
Status: No status
Status: Dev To do
Development

No branches or pull requests

3 participants