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

Fix memory usage in catalog operator #362

Merged
merged 2 commits into from
Jun 1, 2018

Conversation

ecordell
Copy link
Member

@ecordell ecordell commented May 31, 2018

Also scopes the catalog operator to only watch the "catalogNamespace" for catalog sources (it was watching all before).

Mem usage before:
screen shot 2018-05-31 at 9 26 34 am

Mem usage after:
screen shot 2018-05-31 at 6 12 54 pm

@ecordell ecordell requested review from ericavonb and alecmerdler May 31, 2018 16:54
@ecordell ecordell closed this May 31, 2018
@ecordell ecordell reopened this May 31, 2018
@ecordell ecordell force-pushed the catalog-fixes branch 2 times, most recently from 123a8bb to 1fcfd1c Compare May 31, 2018 20:45
@ecordell
Copy link
Member Author

ecordell commented Jun 1, 2018

(Pipeline is passing now, status is just slow to update)

Copy link
Member

@alecmerdler alecmerdler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine, just some questions that don't block merging.

@@ -69,6 +67,13 @@ func NewOperator(kubeconfigPath string, wakeupInterval time.Duration, operatorNa
subSharedIndexInformers = append(subSharedIndexInformers, nsInformerFactory.Subscription().V1alpha1().Subscriptions().Informer())
}

// Create an informer for each catalog namespace
catsrcSharedIndexInformers := []cache.SharedIndexInformer{}
for _, namespace := range []string{operatorNamespace} {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why range over a slice with a single item?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because I know we'll implement "local" catalogs in the near future, where we'll want to iterate over operatorNamespace ∪ watchedNamespaces instead of just operatorNamespace

@@ -139,7 +142,7 @@ func (o *Operator) syncCatalogSources(obj interface{}) (syncError error) {
defer o.sourcesLock.Unlock()
o.sources[catsrc.GetName()] = src
o.sourcesLastUpdate = timeNow()
return err
return nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We mix this convention in the codebase (we know err == nil, but return err anyway). Which is preferred?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel this is clearer, but I don't know if there's a golang convention for this. Which do you think is more readable?

@@ -21,23 +21,22 @@ const (

// ConfigMapCatalogResourceLoader loads a ConfigMap of resources into the in-memory catalog
type ConfigMapCatalogResourceLoader struct {
Catalog *InMem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the change in this interface?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fixing the memory leak, since the catalog returned was a field of the loader, and the loader holds a reference to part of the operator (operator client), every time we sync the catalog we were loading into memory and retaining it indefinitely.

We might still be leaking the loader itself now that you mention it...but at least that's a tiny amount instead of an entire in memory catalog

@ecordell ecordell merged commit 5df00ae into operator-framework:master Jun 1, 2018
@ecordell ecordell deleted the catalog-fixes branch June 13, 2018 12:19
njhale pushed a commit to njhale/operator-lifecycle-manager that referenced this pull request Sep 10, 2018
ecordell added a commit to ecordell/operator-lifecycle-manager that referenced this pull request Mar 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants