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 Jul 3, 2023. It is now read-only.
Hi Humans, thanks for open sourcing this repo :).
I would like to know how do you handle non ecs tasks/containers regarding resource available, in particular the "standalone" docker container ecs-logs that is lunched when the vm start, do you trust the foot print will be low enough that you can dismiss it, like ecs-agent, or you impose some kind of constrains(--memory, --cpu..)?
AFAIU the ECS scheduler wont take those into account when scheduling work .
The text was updated successfully, but these errors were encountered:
Indeed, we just don't set limits on ecs-agent or ecs-logs. These don't use too much resources and we don't run at 100% resource usages so there's always some room for OS-related processes.
There are other things that ECS doesn't have control over on our infrastructure, like the datadog agent or lower-level components like journald so it's a good idea to leave a bit of room on the hosts for these to execute. Usually we don't go over 90% reservation on the hosts.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi Humans, thanks for open sourcing this repo :).
I would like to know how do you handle non ecs tasks/containers regarding resource available, in particular the "standalone" docker container ecs-logs that is lunched when the vm start, do you trust the foot print will be low enough that you can dismiss it, like ecs-agent, or you impose some kind of constrains(--memory, --cpu..)?
AFAIU the ECS scheduler wont take those into account when scheduling work .
The text was updated successfully, but these errors were encountered: