operator-sdk
operator-sdk copied to clipboard
operator-framework
Unusually High Core Usage with Upstream Docker Image for helm operator.
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
@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!
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
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