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 · 1 comment
Open
Assignees
Labels
language/helm Issue is related to a Helm operator project 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!

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 triage/support Indicates an issue that is a support question.
Projects
None yet
Development

No branches or pull requests

3 participants