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

[r4rajat]

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,

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.

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

[varshaprasad96]

@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]

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-bot]

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-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.