Question

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

短时间负载测试工作正常。但是长时间运行的负载测试显示docker容器重新生成错误代码137。

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

由于错误137是与内存相关的修复程序已经尝试过。

更改了垃圾收集模式：

＆LT; ServerGarbageCollection＆GT;真＆LT; / ServerGarbageCollection＆GT; ＆LT; ConcurrentGarbageCollection＆GT;真＆LT; / ConcurrentGarbageCollection＆GT;

迁移到netcore 2.0.3，因为它有一些内存管理修复程序。

FROM microsoft / dotnet：2.0.3-runtime

已配置的cgroup，如下所示是docker logs中的一些错误

cgroup：docker-runc（3365）为控制器创建嵌套cgroup＆＃34;内存＆＃34;它有不完整的层次结构支持嵌套的cgroup可能会在将来改变行为。 [23.104548] cgroup：＆＃34;记忆＆＃34;需要在根
上将use_hierarchy设置为1

我们的ECS任务配置如下：

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

一些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 container ip和port上运行load test。他们工作得很好。如果我们通过ALB运行它们，则会发现崩溃行为。

请告诉我任何其他linux命令，它可以为我提供进程终止的实际原因或上述案例的任何可能的修复。

Answer 1

ALB请求你的heatlhcheck响应是否很好？

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

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

1 个答案: