AWS ECS法门的上限

Question

对于使用Fargate启动的容器，默认的ULIMIT "NOFILE“设置为1024。因此，如果我有一个集群，假设有10个服务，每个服务有两个或三个任务(都运行在Fargate上)，如果我将它们全部设置为使用一个巨大的NOFILE数(比如900000 )，会有什么意义呢？

更具体地说，我们需要关心主机吗？我的假设是，如果我使用EC2启动类型并将所有任务设置为有效地使用任意数量的文件，那么托管EC2实例很容易就会不堪重负。或者主机不会不堪重负，但是在主机上注册的容器会得到一个先到先得的文件，它们可以打开的文件数量可能会导致一个服务饥饿另一个？但是，由于我们不管理EC2上的实例，为所有服务设置尽可能高的ULIMIT有什么害处？我们的容器是否并排放置在主机上，从而共享主机资源限制。还是每个服务/每个任务都有一个主机？

当然，我的假设可能是错误的。

Answer 1

对fargate的最大nofile限制为4096。

承载在Fargate上的

Amazon任务使用操作系统设置的默认资源限制值，但nofile资源限制参数除外。nofile资源限制设置容器可以使用的打开文件数量的限制。默认nofile软限制为1024，硬限制为4096。

https://docs.aws.amazon.com/AmazonECS/latest/userguide/task_definition_parameters.html

Answer 2

对这个答案稍作更正。与链接的文档状态一样，这些都是ulimit的默认软和硬限制。您可以通过更新ECS任务定义来重写此操作。Ulimit设置位于定义的ContainerDefinitions部分之下。

我已经成功地使用这种方法为我的AWS Fargate任务设置了nofile的软和硬限制。

因此，虽然您不能使用Linux "ulimit -n“命令动态地更改它，但是您可以通过ECS定义来修改它。

编辑:我做了一些测试，在发行版上运行，我可以在NOFILE =1024x1024= 1048576文件中最大。

​

{
  "ulimits": [
    {
      "name": "nofile",
      "softLimit": 1048576,
      "hardLimit": 1048576
    }
  ],
}

​

添加到其中的任何整数倍数(1024x1024xint)都会导致ECS在尝试启动ECS Fargate任务时报告错误：

CannotStartContainerError: ResourceInitializationError:未能创建新容器运行时任务:未能创建shim任务: OCI运行时创建失败:ResourceInitializationError创建失败:无法启动容器进程:容器期间出错

希望这能帮上忙。

请参阅：https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-containerdefinitions-ulimit.html