AWS ECS docker 容器随机崩溃，netcoreapp2.0 的错误代码为 137

Question

我们最近将 .net4.6 WEB API 迁移到 netcoreapp2.0 我们正在使用 AWS ECS docker 容器来部署我们的服务。

短时间负载测试工作正常。 但长时间运行的负载测试表明 docker 容器回收时出现错误代码 137。

在整个负载测试期间，内存和 CPU 利用率均正常 ~30 %。

由于错误 137 与内存相关，因此已尝试以下修复。

1. 已更改垃圾收集模式：

真true

1. 已迁移到 netcore 2.0.3，因为它对内存管理进行了一些修复。

FROM microsoft/dotnet:2.0.3-runtime

1. 已配置 cgroup，如下是 docker 日志中的一些错误

cgroup: docker-runc (3365) 为具有不完整层次结构支持的控制器“内存”创建了嵌套 cgroup。嵌套的 cgroup 将来可能会改变行为。 [23.104548] cgroup：“内存”需要在根目录上将 use_hierarchy 设置为 1

我们的 ECS 任务配置如下：

1. 正在运行的任务数：2 on 2 C4.xlarge EC2 在 ECS 后面。
2. 内存软限制：2 Gb
3. 还验证了我们的 Healthcheck 端点，它没有任何问题并且响应速度很快。甚至尝试用 200 Ok 对 healthcheck 进行硬编码

一些 Docker 日志：（注意 OOM 被杀死是假的，即使没有内核级别的日志。）

 "State": {
        "Status": "exited",
        "Running": false,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 0,
        "ExitCode": 137,
        "Error": "",
        "StartedAt": "2018-02-12T06:15:00.481719209Z",
        "FinishedAt": "2018-02-12T07:13:02.962733905Z"
    },

如果我们直接在 docker 容器 ip 和端口上运行负载测试，会发现一些奇怪的现象。他们工作得很好。如果我们通过 ALB 运行它们，则会观察到崩溃行为。

请让我知道任何其他 linux 命令，这些命令可以为我提供进程终止的实际原因或上述情况的任何可能的修复。

Answer 1

您对 ALB 请求的 heatlhcheck 响应是否良好？

137 退出代码表示您的容器已被 ECS 代理杀死。