Skip to content
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

WEB_CONCURRENCY is miscalculated on ECS Fargate #220

Open
ipmb opened this issue Mar 23, 2022 · 3 comments
Open

WEB_CONCURRENCY is miscalculated on ECS Fargate #220

ipmb opened this issue Mar 23, 2022 · 3 comments

Comments

@ipmb
Copy link

ipmb commented Mar 23, 2022

Splitting this out from #210... When running on Fargate with 512MB of RAM, WEB_CONCURRENCY is set to 28. My expectation is that it would be set to 1 (or not set at all).

It looks like the calculations are taken from the following files. Their values on Fargate are:

$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
9223372036854771712
$ cat /sys/fs/cgroup/memory/memory.max
cat: /sys/fs/cgroup/memory/memory.max: No such file or directory

It's not yet clear to me the best way to determine how much RAM is available in a Fargate container, but I have an open issue with AWS support and will update when I hear back.

@joshwlewis
Copy link
Member

$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
9223372036854771712

That seems like a bit more than 512MB! For what it's worth, I think dokku setups return a similarly large value. I would be interested to hear if there is a better way to arrive at this number on fargate.

@ipmb
Copy link
Author

ipmb commented Apr 7, 2022

Fargate lets you set memory in two places, the "task" and the "container". If you set the container memory, this calculation works as expected. If you only set the task memory, there's no way (short of the API) to determine the value from inside the container.

@edmorley
Copy link
Member

edmorley commented Mar 14, 2024

That seems like a bit more than 512MB! For what it's worth, I think dokku setups return a similarly large value. I would be interested to hear if there is a better way to arrive at this number on fargate.

Yeah I dug into this more for heroku/heroku-buildpack-python#1547 - it turns out for cgroups v1 (older Docker and others) if there is no container memory limit is set, then instead of the /sys/fs/cgroup/memory/memory.limit_in_bytes file being missing, it's created with a nonsensically high value instead. In contrast for cgroups v2, if no limit is set, then the /sys/fs/cgroup/memory.max file instead contains the value "max".

Since this issue was opened, the implementation for heroku/nodejs-engine has been changed to now use a cap:
#764
(However, this still gives the wrong value for the Fargate use-case I believe?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants