-
Notifications
You must be signed in to change notification settings - Fork 689
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
Stacking LDS updates cause non-deterministic Envoy memory usage #1635
Comments
Thank you for raising this issue.
I think the best solution to this is FDS which we’re waiting on. Maybe it’ll come in envoy 1.12.
With that said I understand the issues that frequent LDS update cause in your environment and I will continue to work to reduce them. I don’t have a concrete eta on when this will happen or what it will involve but 499 and related issues remain a high priority for me.
… On 5 Oct 2019, at 02:13, Brandon Cook ***@***.***> wrote:
We regularly see 3+ total_listeners_draining in Envoy stats. Each of these has a full set of filter chain matches and consume quite a bit of memory for our 200+ FQDNs
Regardless of any changes in Envoy (see envoyproxy/envoy#7923), Contour should Ensure LDS doesn't stack up in Envoy. There should be a guarantee of, for example, 2 ingress_http (at most 1 draining) + 2 ingress_https (at most 1 draining) listeners as an upper bound
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
The Contour project currently lacks enough contributors to adequately respond to all Issues. This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
The Contour project currently lacks enough contributors to adequately respond to all Issues. This bot triages Issues according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
We regularly see 3+
total_listeners_draining
in Envoy stats. Each of these has a full set of filter chain matches and consume quite a bit of memory for our 200+ FQDNsRegardless of any changes in Envoy (see envoyproxy/envoy#7923), Contour should ensure LDS doesn't stack up in Envoy. There should be a guarantee of, for example, 2
ingress_http
(at most 1 draining) + 2ingress_https
(at most 1 draining) listeners as an upper boundThe text was updated successfully, but these errors were encountered: