You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.
we currently benchmark the operator to reflect real situration where tens of jobs come up concurrently.
we observe an issue where the submitters pods reach each one consume 1000m+ cpu. since there are no resources what so ever for the submitter k8s job, they are filling the nodes and easily making the nodes choke. since we dont control the submitter nodeselector this also influences the JobManagers on these nodes since they dont come up since the node is on 100% because of the submitters (we currently solve this with taints and tolerations for the other workloads) but it would really make it easy to control the submitters requests,limits and nodeselectors.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
we currently benchmark the operator to reflect real situration where tens of jobs come up concurrently.
we observe an issue where the submitters pods reach each one consume 1000m+ cpu. since there are no resources what so ever for the submitter k8s job, they are filling the nodes and easily making the nodes choke. since we dont control the submitter nodeselector this also influences the JobManagers on these nodes since they dont come up since the node is on 100% because of the submitters (we currently solve this with taints and tolerations for the other workloads) but it would really make it easy to control the submitters requests,limits and nodeselectors.
The text was updated successfully, but these errors were encountered: