Bug 1371277

Summary:	etcd cache size default value set to 50K causing high memory usage
Product:	OpenShift Container Platform	Reporter:	Vikas Laad <vlaad>
Component:	RFE	Assignee:	Timothy St. Clair <tstclair>
Status:	CLOSED NOTABUG	QA Contact:	Chuan Yu <chuyu>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	agoldste, aos-bugs, decarr, jokerman, mkhan, mmccomas, vlaad
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-25 22:11:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Vikas Laad 2016-08-29 18:33:15 UTC

Description of problem:
Please see bug https://bugzilla.redhat.com/show_bug.cgi?id=1323733 using this bug etcd cache size was made configurable so that high memory consumption can be avoided. Currently default value is still set to 50K which causes again same problem until its set to lower number in master-config.

Version-Release number of selected component (if applicable):
openshift v3.3.0.22
kubernetes v1.3.0+507d3a7
etcd 2.3.0+git


How reproducible:
Long running tests can reproduce this problem.

Actual results:
Default value set to 50K causes high memory consumption.

Expected results:
This value should be set to lower number by default, not sure what that number should be.

Additional info:

Comment 1 Andy Goldstein 2016-08-30 14:05:28 UTC

Not a release blocker given that you can set this value in the master config.

Comment 2 Seth Jennings 2016-09-08 14:31:22 UTC

Current PR:
https://github.com/openshift/origin/pull/10719

Comment 3 Derek Carr 2016-10-26 17:31:35 UTC

Not a release blocker, need to have platform team decide if origin wants to change how caches are handled.  We can iterate on Seth's PR, but its not really a bug.  Personally, I think this should be closed and we should have an RFE to handle this.  Moving this to RFE component.

Comment 7 Timothy St. Clair 2017-01-25 22:11:16 UTC

The original title of this BZ no longer applies, I will open an upstream issue on determining proper sizing of the deserialization cache, and link back to this issue.