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

Test CPU and memory usage of Crossplane and providers #1846

Closed
muvaf opened this issue Oct 14, 2020 · 5 comments
Closed

Test CPU and memory usage of Crossplane and providers #1846

muvaf opened this issue Oct 14, 2020 · 5 comments
Labels
enhancement New feature or request good first issue Good for newcomers performance
Projects

Comments

@muvaf
Copy link
Member

muvaf commented Oct 14, 2020

What problem are you facing?

If I want to deploy Crossplane with some resource limits, I don't have much information other than guessing what it needs.

How could Crossplane help solve your problem?

We can test Crossplane & providers for resource usage and write down what affects the usage (how much a new XRD increases CPU usage?) so that users can reliably deploy it.

@muvaf muvaf added the enhancement New feature or request label Oct 14, 2020
@hasheddan
Copy link
Member

xref: #314

@jbw976
Copy link
Member

jbw976 commented Nov 10, 2020

I think it's a really good idea to understand our resource usage needs, especially with memory consumption. We've seen some provider pods (e.g. provider-aws) get OOM killed recently, so I'm wondering if memory usage has increased in recent releases.

We should at least do a memory profile to understand what our memory usage/needs are, and to see if there is any low hanging fruit of obvious fixes that we should put in as part of our v1.0.0 hardening efforts to be less resource intensive.

/cc @prasek @lukeweber

@jbw976 jbw976 added this to Proposed in v1.0 Nov 10, 2020
@khos2ow
Copy link
Contributor

khos2ow commented Dec 4, 2020

@jbw976 In #1940 we're enabling metrics by tapping into metrics server controller-runtime provides. There's also a way to extend that and add customized metrics (which I don't remember off the top of my head), but at the bare minimum some good handful of metrics are available (can be found here). That being said even proceeding with #1940 doesn't enable metrics gathering from providers, but it's gonna be very simple to add that (essentially a port definition and couple of annotation is needed).

On the other hand, neither of these will cover memory profiling, which I've done previously for some other projects and I can either squeeze it in the same PR or in a new one. Something like exposing additional /debug/pprof/ endpoints.

@negz negz moved this from Proposed to Accepted in v1.0 Dec 8, 2020
@prasek prasek added this to Proposed in v1.1 Dec 8, 2020
@negz negz removed this from Accepted in v1.0 Dec 8, 2020
@negz negz added the good first issue Good for newcomers label Dec 14, 2020
@muvaf muvaf removed this from Proposed in v1.1 Jan 25, 2021
@muvaf
Copy link
Member Author

muvaf commented Mar 30, 2022

#2983 will tackle the provider part of this by providing a tool to run standardized tests against common metrics. At the same time, you can test for CPU & memory usage just like any other Kubernetes pod.

@stale
Copy link

stale bot commented Aug 14, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Aug 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers performance
Projects
No open projects
On-Duty
Awaiting triage
Development

No branches or pull requests

5 participants