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

Unusually High Core Usage with Upstream Docker Image for helm operator. #6679

Open
r4rajat opened this issue Feb 14, 2024 · 3 comments
Open
Assignees
Labels
language/helm Issue is related to a Helm operator project lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. triage/support Indicates an issue that is a support question.
Milestone

Comments

@r4rajat
Copy link

r4rajat commented Feb 14, 2024

Bug Report

What did you do?

I am creating an helm based operator for Redhat Openshift. Earlier I was using the downstream image i.e registry.redhat.io/openshift4/ose-helm-operator:latest as my base image and my operator-controller-manager deployment was taking around 0.06-0.08 cores,
image

Then I updated my base image to the upstream image i.e quay.io/operator-framework/helm-operator:latest and the core usage for the same operator-controller-manager increased very much to like 0.8-0.9 cores.
image

What did you expect to see?

Usual core usage around 0.05-0.06

What did you see instead? Under which circumstances?

Very high core usage around 1

Environment

Operator type:

/language helm

Kubernetes cluster type:

OpenShift v4.13.4

$ operator-sdk version

root@rajat-gupta:/repo# operator-sdk version
operator-sdk version: "v1.24.1", commit: "1a1c56f7d0c7cfcc16e1ff2140caaa6d831b669b", kubernetes version: "1.24.2", go version: "go1.18.7", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

root@rajat-gupta:/repo# go version
go version go1.21.6 linux/amd64

$ kubectl version

root@rajat-gupta:/repo# kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.7", GitCommit:"07a61d861519c45ef5c89bc22dda289328f29343", GitTreeState:"clean", BuildDate:"2023-10-18T11:42:32Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.5+7d22122", GitCommit:"2fc599b5fd3f060dd20094b520f0f529fd2f52db", GitTreeState:"clean", BuildDate:"2023-06-07T20:30:17Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Additional context

@openshift-ci openshift-ci bot added the language/helm Issue is related to a Helm operator project label Feb 14, 2024
@jberkhahn jberkhahn added the triage/support Indicates an issue that is a support question. label Apr 8, 2024
@jberkhahn jberkhahn added this to the Backlog milestone Apr 8, 2024
@varshaprasad96
Copy link
Member

@r4rajat Could you specify what version (and SHA) you are referring to for the respective upstream and downstream latest tags?

Also, it would be super helpful if you could run a profiler and let us know what is actually consuming the memory. Due to a shortage of active maintainers, its maybe really difficult for us to pick this up. Any help in solving this would be greatly appreciated!

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 8, 2024
@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language/helm Issue is related to a Helm operator project lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. triage/support Indicates an issue that is a support question.
Projects
None yet
Development

No branches or pull requests

4 participants