共计 1135 个字符，预计需要花费 3 分钟才能阅读完成。
问题
在一个 python 镜像中, 要用到 pip install -r requirements
FROM python:3.7
WORKDIR /code
EXPOSE 80
COPY ./code/requirements.txt requirements.txt
RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
CMD ["gunicorn", "-w", "4", "-b", "0.0.0.0:80", "wsgi:app"]然而在构建镜像的过程中, 失常状况下, docker 会将容器内所有信息打印进去.
但 build 过程中, docker 容器非正常退出. 错误信息没有报进去
说实话, 很形象. 仅有 return code 137
哪怕镜像没有构建实现, 能够通过 docker ps -a 查看镜像构建时的退出码
但无奈应用 docker logs 命令查看尚未构建好的镜像的日志
按情理而言, 若 pip 命令出错, docker build 会将错误信息打印进去. 但 killed 示意 docker 容器是非正常退出.
而该 return code 137 有很多种起因呈现
- 容器承受到 SIGKILL 信号, 通常状况下代表容器内存溢出, 导致程序异样退出
- 容器被 docker 发送命令, 命令强制敞开容器
利用 top 命令监控
top 命令执行后, 按 m 键会依照应用内存降序排序
解决办法
调整 docker container 的内存限度
应用 docker info 命令, 查看 docker 根本配置信息
服务器就 2G 内存, docker 能够应用 memory 是 1.936GiB
最初一行则示意 docker 容器会尽可能的应用宿主的 CPU 和内存资源. 这也是 Linux 零碎下 docker 的默认设置
这意味着 docker container 容器部署时, 曾经充分利用容器内存.
top 命令, 一开始是稳固 5% MEM, 忽然飙升到 40%, 而后就 killed 了
仿佛只能降级服务器内存呢. 最初还是放弃应用 docker 部署, 间接在主机上安装 python 环境.
问题的起因是因为 requirement.txt 中须要装置的包过大, (如 PyTorch 和 TensorFlow 都须要装置). pip 没有足够的内存进行装置, 导致应用的内存过多而被零碎检测发送 SIGKILL 终止创立.
Docker 应用采纳 Linux 的 subsystem 技术, 实现对容器内过程应用资源做限度和跟踪
参考
- Docker-compose exit code is 137 when there is no OOM exception
- How to increase/check default memory Docker has on linux?
- Understanding Docker Container Exit Codes
