-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Set memory limit #3332
Set memory limit #3332
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not an elasticsearch expert but 500M sounds like quite a low limit for elasticsearch to begin with. IIRC it's usually run with gigabytes of heap.
/assign @mdemirhan |
AIUI this value wont prevent this process OOMing - it is just a cgroups limit and scheduler hint that will OOM the process at this level. I believe you can set memory limits for java ES uses this way:
|
022a9e2
to
7213538
Compare
I updated the first comment to better reflect the issue. I'm open to other values but w/o this we're seeing our Nodes OOM'ing instead of just the Pod, which should just recycle nicely when it OOM's. |
7213538
to
a632903
Compare
a632903
to
08827cd
Compare
There were a couple of other Deployments in serving that needed limits too. I raised the limit to 1G. |
/test pull-knative-serving-integration-tests |
08827cd
to
861f408
Compare
/test pull-knative-serving-integration-tests |
/test pull-knative-serving-upgrade-tests |
/test pull-knative-serving-integration-tests |
Changes in monitoring components seem fine, but we shouldn't really change Istio YAML files. Those are mostly generated from the latest istio helm charts and next time we upgrade istio, it will be overridden. Istio changes should happen via Istio's github project. |
@mdemirhan ok I removed the Istio ones - thanks! |
ping @mdemirhan @markusthoemmes for review |
@@ -94,6 +94,7 @@ spec: | |||
name: elasticsearch-logging | |||
resources: | |||
limits: | |||
memory: 1000Mi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am worried that 1gig might be too little for Elastic Search. In these memory constraint environments, it might be better to not install Elastic Search at all and undo this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to changing it - what value would you be more comfortable with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a good answer to that, but the recommendation from ES is to have as much as you can afford - https://qbox.io/support/article/choosing-a-size-for-nodes
We're seeing OOM issues when we don't see the limit Signed-off-by: Doug Davis <dug@us.ibm.com>
Signed-off-by: Doug Davis <dug@us.ibm.com>
Signed-off-by: Doug Davis <dug@us.ibm.com>
@mdemirhan I removed third_party/config/monitoring/logging/elasticsearch/elasticsearch.yaml and third_party/config/monitoring/logging/elasticsearch/kibana.yaml thinking that I should edit those some place else too, but I'm not seeing where those might be coming from. Are those files generated too or hand-crafted? |
This is the "build" version of knative/serving#3332 We're seeing OOM issues at the Node level when we don't set the limit. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. Signed-off-by: Doug Davis <dug@us.ibm.com>
* Set memory limits This is the "build" version of knative/serving#3332 We're seeing OOM issues at the Node level when we don't set the limit. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. Signed-off-by: Doug Davis <dug@us.ibm.com> * Fix indentation
Those files are mostly hand crafted and we don't continuously update them. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: duglin, mdemirhan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-knative-serving-upgrade-tests |
/test pull-knative-serving-upgrade-tests |
/test pull-knative-serving-integration-tests |
We're seeing OOM issues at the Node level when we don't set the limit on some pods. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. See knative/serving#3332 for the serving equivalent. Signed-off-by: Doug Davis <dug@us.ibm.com>
We're seeing OOM issues at the Node level when we don't set the limit on some pods. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. See knative/serving#3332 for the serving equivalent. Signed-off-by: Doug Davis <dug@us.ibm.com>
We're seeing OOM issues at the Node level when we don't set the limit on some pods. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. See knative/serving#3332 for the serving equivalent. Signed-off-by: Doug Davis <dug@us.ibm.com>
We're seeing OOM issues at the Node level when we don't set the limit on some pods. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. See knative/serving#3332 for the serving equivalent. Signed-off-by: Doug Davis <dug@us.ibm.com>
* Set memory limits This is the "build" version of knative/serving#3332 We're seeing OOM issues at the Node level when we don't set the limit. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. Signed-off-by: Doug Davis <dug@us.ibm.com> * Fix indentation
* Set memory limits This is the "build" version of knative/serving#3332 We're seeing OOM issues at the Node level when we don't set the limit. This will allow the pod to restart gracefully w/o taking down the entire node. I'm not stuck on the specific value so we can pick a different one. Signed-off-by: Doug Davis <dug@us.ibm.com> * Fix indentation
We're seeing OOM issues at the Node level when we don't set the limit. This will allow the pod to restart gracefully w/o taking down the entire node.
I'm not stuck on the specific value so we can pick a different one.
Signed-off-by: Doug Davis dug@us.ibm.com
/lint
Release Note