Skip to content

use realistic coturn memory limits #50

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.

Sign up for GitHub

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

Open
mastaab wants to merge 1 commit into
base: wireapp/4.6.2-federation
Choose a base branch
from
Open

use realistic coturn memory limits #50

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions charts/coturn/values.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,13 +23,11 @@ externalIpHelper:
# important that they run on disjoint sets of nodes, you can use nodeSelector to enforce this
nodeSelector: {}

# Limiting memory usage to ~90% of the available memory on a 8Gb node which is used for coturn pods by default.
# This is to prevent the pod from being OOM kill
resources:
requests:
memory: 512Mi
memory: 256Mi
limits:
memory: 6.5Gi
memory: 512Mi

@jschumacher-wire jschumacher-wire Jun 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I'm not sure we should be as agressive. A single coturn pod usually owns its node anyway and we should leave it up to the operator to set mem limits to whatever the node can tolerate.

@mastaab mastaab Jun 23, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

The main reason for this change is, that this limit is setting false expectations and lead to false sizing assumptions.
In prod, there is no coturn pod that is using more than 150mb. If a customer is sizing their coturn nodes, and they are driven by the limits here, the will be way too big and are just inflating the compute requirements (which especially on-prem need to be really tailored to what we need)
One can always overwrite the limits of course, but from my perspective the standard should reflect the reality.
Wdyt?


initResources:
requests:
Expand Down