您的位置  娱乐资讯

一次 Docker 容器内大量僵尸进程排查分析

  • 来源:互联网
  • |
  • 2019-12-25
  • |
  • 0 条评论
  • |
  • |
  • T小字 T大字

前段时间线上的一个使用 Google Puppeteer 生成图片的服务炸了,每个 docker 容器内都有几千个孤儿僵死进程没有回收,如下图所示。

这篇文章比较长,主要就讲了下面这几个问题。

  • 什么情况下会出现僵尸进程、孤儿进程
  • Puppeteer 工作过程启动的进程与线上事故分析
  • PID 为 1 的进程有什么特殊的地方
  • 为什么 node/npm 不应该作为镜像中 PID 为 1 的进程
  • 为什么 Bash 可以作为 PID 为 1 的进程,以及它做 PID 为 1 的进程有什么缺陷
  • 镜像中比较推荐的 init 进程的做法是什么

Puppeteer 是一个 node 库,是 Chrome 官方提供的无界面 chrome 工具(headless chrome),它提供了操作 Chrome API 的方式,允许开发者在程序中启动 chrome 进程,调用 JS 的 API 实现页面加载、数据爬取、web 自动化测试等功能。

本案例中使用的场景是使用 Puppeteer 加载 html,随后截图生成一张分销海报的图片。文章分析了这个问题背后的原因,接下来开始正式的内容。

进程

每个进程都有一个唯一的标识,称为 pid,pid 是一个非负的整数值,使用 ps 命令可以查看,在我的 Mac 电脑上执行 ps -ef 可以看到当前运行的所有进程,如下所示。

UID   PID  PPID   C STIME   TTY           TIME CMD  0     1     0   0 六04下午 ??        23:09.18 /sbin/launchd  0    39     1   0 六04下午 ??         0:49.66 /usr/sbin/syslogd  0    40     1   0 六04下午 ??         0:13.00 /usr/libexec/UserEventAgent (System)

其中 PID 是表示进程号。

系统中每个进程都有对应的父进程,上面 ps 输出中的 PPID 就表示进程的父进程号。最顶层的进程的 PID 为 1,PPID 为 0。

打开 iTerm,在终端中执行一个命令,比如 "ls",实际上系统会创建新的 iTerm 子进程,这个 iTerm 进程又创建了 zsh 子进程。在 zsh 中输入的 ls 命令,则是 zsh 进程又启动了一个 ls 子进程。在 iTerm 中输入 ls 命令过程的进程关系如下所示。

  UID   PID  PPID   C STIME   TTY           TIME CMD  501   321     1   0 六04下午 ??        61:01.45 /Applications/iTerm.app/Contents/MacOS/iTerm2 -psn_0_81940  501 97920   321   0  8:02上午 ttys039    0:00.07 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server login -fp arthur    0 97921 97920   0  8:02上午 ttys039    0:00.03 login -fp arthur  501 97922 97921   0  8:02上午 ttys039    0:00.29 -zsh  501 98369 97922   0  8:14上午 ttys039    0:00.00 ./a.out

进程与 fork

前面提到的父进程“创建”子进程,更严谨的描述是 fork(孵化、衍生)。下面来看一个实际的例子,新建一个 fork_demo.c 文件。

#include #include int main() {  int ret = fork();  if (ret) {    printf("enter if block/n");  } else {    printf("enter else block/n");  }  return 0;}

执行上的代码,会输出如下的语句。

enter if blockenter else block

可以看到 if、else 语句都被执行了。

fork 调用

fork 是一个系统调用,它的方法声明如下所示。

pid_t fork(void);

fork 调用完成后会生成一个新的子进程,且父子进程都从 fork 返回处继续执行。这里需要特别注意的是 fork 的返回值的含义,在父进程和新的子进程中,它们的含义不一样。

  • 在父进程中 fork 的返回值是新创建的子进程 id
  • 在创建的子进程中 fork 的返回值始终等于 0

因此可以通过 fork 的返回值区分父子进程,在运行过程中可以使用 getpid 方法获取当前的进程 id。fork 典型的使用方式如下所示。

#include #include #include int main() {  printf("before fork, pid=%d/n", getpid());  pid_t childPid;  switch (childPid = fork()) {    case -1: {      // fork 失败      printf("fork error, %d/n", getpid());      exit(1);    }    case 0: {      // 子进程代码进入到这里      printf("in child process, pid=%d/n", getpid());      break;    }    default: {      // 父进程代码进入到这里      printf("in parent process, pid=%d, child pid=%d/n", getpid(), childPid);      break;    }  }  return 0;}

执行上面的代码,输出结果如下所示。

before fork, pid=26070in parent process, pid=26070, child pid=26071in child process, pid=26071

子进程是父进程的副本,子进程拥有父进程数据空间、堆、栈的复制副本 ,fork 采用了 copy-on-write 技术,fork 操作几乎瞬间可以完成。只有在子进程修改了相应的区域才会进行真正的拷贝。

孤儿进程:不能同年同月同日生,也不会同年同月同日死

接下来问一个问题,父进程挂掉时,子进程会挂掉吗?

想象现实中的场景,父亲不在了,儿子还可以活吗?答案是肯定的。对应于进程,父进程退出时,子进程会继续运行,不会一起共赴黄泉。

一个父进程已经终止的进程被称为孤儿进程(orphan process)。操作系统这个大家长是比较人性化的,没有人管的孤儿进程会被进程 ID 为 1 的进程接管。这个 PID 为 1 的进程后面还会再讲到。

接下来对之前的代码稍作修改,让父进程 fork 子进程以后自杀退出,生成孤儿进程。代码如下所示。

#include #include #include int main() {  printf("before fork, pid=%d/n", getpid());  pid_t childPid;  switch (childPid = fork()) {    case -1: {      printf("fork error, %d/n", getpid());      exit(1);    }    case 0: {      printf("in child process, pid=%d/n", getpid());      sleep(100000); // 子进程 sleep 不退出      break;    }    default: {      printf("in parent process, pid=%d, child pid=%d/n", getpid(), childPid);      exit(0); // 父进程退出    }  }  return 0;}

编译运行上面的代码

gcc fork_demo.c -o fork_demo; ./fork_demo

输出结果如下。

before fork, pid=21629in parent process, pid=21629, child pid=21630in child process, pid=21630

可以看到父进程 id 为 21629, 生成的子进程 id 为 21630。

使用 ps 查看当前进程信息,结果如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 12月12 ?      00:00:53 /usr/lib/systemd/systemd --system --deserialize 21ya       21630     1  0 19:26 pts/8    00:00:00 ./fork_demo

可以看到此时孤儿子进程 21630 的父 ID 已经变为了顶层的 ID 为 1 的进程。

僵尸进程

父进程负责生,如果不负责养,那就不是一个好父亲。子进程挂了,如果父进程不给子进程“收尸”(调用 wait/waitpid),那这个子进程小可怜就变成了僵尸进程。

新建一个 make_zombie.c 文件,内容如下。

#include #include #include int main() {  printf("pid %d/n", getpid());  int child_pid = fork();  if (child_pid == 0) {    printf("-----in child process:  %d/n", getpid());    exit(0);  } else {    sleep(1000000);  }  return 0;}

编译运行上面的代码,就可以生成一个进程号为 22538 的僵尸进程,如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDya       22537 20759  0 19:57 pts/8    00:00:00 ./make_zombieya       22538 22537  0 19:57 pts/8    00:00:00 [make_zombie] 

CMD 名中的 defunct 表示这是一个僵尸进程。

也使用 ps 命令查看进程的状态,显示为 "Z" 或者 "Z+" 表示这是一个僵尸进程,如下所示。

ps -ho pid,state -p 2253822538 Z

子进程退出后绝大部分资源已经被释放可供其他进使用,但是内核的进程表中的槽位没有释放。

僵尸进程有一个很神奇的特性,使用 kill -9 必杀信号都没有办法杀掉僵尸进程,这样的设计利弊参半,好的地方是父进程可以总是有机会执行 wait/waitpid 等命令收割子进程,坏的地方是无法强制回收这种僵尸进程。

PID 为 1 的进程

Linux 中内核初始化以后会启动系统的第一个进程,PID 为 1,也可以称之为 init 进程或者根(ROOT)进程。在我的 Centos 机器上,这个 init 进程是 systemd,如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 12月12 ?      00:00:54 /usr/lib/systemd/systemd --system --deserialize 21

在我的 Mac 电脑上,这个进程为 launchd,如下所示。

UID   PID  PPID   C STIME   TTY           TIME CMD  0     1     0   0 六04下午 ??        28:40.65 /sbin/launchd

init 进程有下面这几个功能

  • 如果一个进程的父进程退出了,那么这个 init 进程便会接管这个孤儿进程。
  • 如果一个进程的父进程未执行 wait/waitpid 就退出了,init 进程会接管子进程并自动调用 wait 方法,从而保证系统中的僵尸进程可以被移除。
  • 传递信号给子进程,这点后面会介绍。

为什么 Node.js 不适合做 Docker 镜像中 PID 为 1 的进程

在 Node.js 的官方最佳实践里有写到 "Node.js was not designed to run as PID 1 which leads to unexpected behaviour when running inside of Docker."。下图来自 github.com/nodejs/dock… 。

接下来会做两个实验:第一个实验是在 Centos 机器上,第二个实验是在 Docker 镜像中

实验一:在 Centos 上,systemd 作为 PID 为 1 的进程

下面来做一些测试,修改上面的代码,将父进程 sleep 的时间改短为 15s,新建一个 make_zombie.c 文件,如下所示。

#include #include #include int main() {  printf("pid %d/n", getpid());  int child_pid = fork();  if (child_pid == 0) {    printf("-----in child process:  %d/n", getpid());    exit(0);  } else {    sleep(15);    exit(0);  }}

编译生成可执行文件 make_zombie。

gcc make_zombie.c -o make_zombie

然后新建一个 run.js 代码,内部启动一个进程运行 make_zombie,如下所示。

const { spawn } = require('child_process');const cmd = spawn('./make_zombie');cmd.stdout.on('data', (data) => {    console.log(`stdout: ${data}`);});cmd.stderr.on('data', (data) => {    console.error(`stderr: ${data}`);});cmd.on('close', (code) => {    console.log(`child process exited with code ${code}`);});setTimeout(function () {    console.log("...");}, 1000000);

执行 node run.js 运行这段 js 代码,使用 ps -ef 查看进程关系如下。

UID        PID  PPID  C STIME TTY          TIME CMDya       19234 19231  0 12月20 ?       00:00:00 sshd: ya@pts/6ya       19235 19234  0 12月20 pts/6   00:00:01 -zshya       29513 19235  3 15:28 pts/6    00:00:00 node run.jsya       29519 29513  0 15:28 pts/6    00:00:00 ./make_zombieya       29520 29519  0 15:28 pts/6    00:00:00 [make_zombie] 复制代码

过 15s 以后,再次执行 ps -ef 查询当前运行的进程,可以看到 make_zombie 相关进程都不见了。

UID        PID  PPID  C STIME TTY          TIME CMDya       19234 19231  0 12月20 ?       00:00:00 sshd: ya@pts/6ya       19235 19234  0 12月20 pts/6   00:00:01 -zshya       29513 19235  3 15:28 pts/6    00:00:00 node run.js

这是因为 PID 为 29519 的 make_zombie 父进程在 15s 以后退出,僵尸子进程被托管到 init 进程,这个进程会调用 wait/waitfor 为这个僵尸收尸。

实验二:在 Docker 上,node 作为 PID 为 1 的进程

将 make_zombie 可执行文件和 run.js 打包为 .tar.gz 包,随后新建一个 Dockerfile,内容如下。

#指定基础镜像FROM  registry.gz.cctv.cn/library/your_node_image:your_tagWORKDIR /#复制包文件到工作目录,. 代表当前目录,也就是工作目录ADD test.tar.gz .#指定启动命令CMD ["node", "run.js"]

执行 docker build 命令构建一个镜像,在我的电脑上 Image ID 为 ab71925b5154, 执行 docker run ab71925b5154,启动 docker 镜像,使用 docker ps 找到镜像 CONTAINER ID,这里为 e37f7e3c2e39。随即使用 docker exec 进入到镜像终端

docker exec -it e37f7e3c2e39 /bin/bash 

执行 ps 命令查看当前的进程状况,如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  1 07:52 ?        00:00:00 node run.jsroot        12     1  0 07:52 ?        00:00:00 ./make_zombieroot        13    12  0 07:52 ?        00:00:00 [make_zombie] 

等一段时间(15s),再次执行 ps 查看当前进程,如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 07:52 ?        00:00:00 node run.jsroot        13     1  0 07:52 ?        00:00:00 [make_zombie] 

可以看到 PID 为 13 的僵尸进程已经托管到 PID 为 1 的 node 进程,但是没有被回收。

这是 node 不适合做 init 进程的最主要原因:无法回收僵尸进程。

说到 node,这里提一下 npm,npm 实际上是使用 npm 进程启动了一个子进程启动了 package.json 中 scripts 里写的启动脚本,示例 package.json 脚本如下所示。

{  "name": "test-demo",  "version": "1.0.0",  "description": "",  "main": "index.js",  "scripts": {    "test": "echo /"Error: no test specified/" && exit 1",    "start": "node run.js"  },  "keywords": [],  "author": "",  "license": "ISC",  "dependencies": {  }}

使用 npm run start 启动,得到的进程如下所示。

ya       19235 19234  0 12月20 pts/6  00:00:01 -zshya       32252 19235  0 16:32 pts/6    00:00:00 npmya       32262 32252  0 16:32 pts/6    00:00:00 node run.js

与 node 一样,npm 也不会处理僵尸子进程回收。

线上问题分析

我们线上出问题的情况下使用 npm start 来启动一个 Puppeteer 项目,每生成一次图片便会创建 4 个 chrome 相关的进程,如下所示。

.|└── chrome(1)    ├── gpu-process(2)    └── zygote(3)        └── renderer(4)

在图片生成完成时,chrome 主进程退出,剩下的三个孤儿僵尸进程被托管到顶层 npm 进程下,但是 npm 进程无力回收,所有每生成一次图片便会新增三个僵尸进程。在成千上万次图片生成以后,系统中就充满了僵尸进程。

解决办法

为了解决这个问题,不能让 node/npm 成为 init 进程,让有能力接管僵尸进程的服务成为 init 进程即可,有两个解决办法。

  • 使用 bash 启动 node 或者 npm
  • 增加专门的 init 进程,比如 tini

解决方式一:使用 bash 启动 node

让 bash 成为顶层进程是比较快的一种方式,bash 进程会负责回收僵尸进程,修改 Dockerfile,如下所示。

ADD test.tar.gz .# CMD ["npm", "run", "start"]CMD ["/bin/bash", "-c", "set -e && npm run start"]

使用这种方式是比较简单,而且之前线上没有出问题正是因为一开始是使用这种 bash 方式启动 node,后面有一个小兄弟为了统一启动命令将这个命令改为 npm run start,问题才出现的。

但使用 bash 并非完美的方案,它有一个比较严重的问题,bash 不会传递信号给它启动的进程,优雅停机等功能无法实现。

接下来做一个实验,验证 bash 不会传递信号给子进程的说法,新建一个 signal_test.c 文件,它处理 SIGQUIT、SIGTERM、SIGTERM 三个信号,内容如下。

#include #include static void signal_handler(int signal_no) {  if (signal_no == SIGQUIT) {    printf("quit signal receive: %d/n", signal_no);  } else if (signal_no == SIGTERM) {    printf("term signal receive: %d/n", signal_no);  } else if (signal_no == SIGTERM) {    printf("interrupt signal receive: %d/n", signal_no);  }}int main() {  printf("in main/n");  signal(SIGQUIT, signal_handler);  signal(SIGINT, signal_handler);  signal(SIGTERM, signal_handler);  getchar();}

在我 Centos 和 Mac 上运行这个 signal_test 程序时,发送 kill -2、-3、-15 给这个程序,都会有对应的打印输出,表示收到了信号。如下所示。

kill -15 47120term signal receive: 15kill -3 47120quit signal receive: 3kill -2 47120interrupt signal receive: 2

在 Docker 镜像中使用 bash 启动这个程序时,发送 kill 命令给 bash 以后,bash 并不会将信号传递给 signal_test 程序。在执行 docker stop 以后,docker 会发送 SIGTERM(15) 信号给 bash,bash 并不会将这个信号传递给启动的应用程序,只能等一段时间超时,docker 会发送 kill -9 强制杀死这个 docker 进程,无法达到优雅停机的功能。

于是有了下面的第二种解决方案。

解决方式二:使用专门的 init 进程

Node.js 提供了两种方案,第一种是使用 docker 官方的轻量级 init 系统,如下所示。

docker run -it --init you_docker_image_id

这种启动方式会以 /sbin/docker-init 为 PID 为 1 的 init 进程,不会把 Dockerfile 中 CMD 作为第一个启动进程。

以下面的 Dockerfile 内容为例

...CMD ["./signal_test"]...

执行 docker run -it --init image_id 启动 docker 镜像,此时镜像内的进程如下所示。

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 15:30 pts/0    00:00:00 /sbin/docker-init -- /app/node-defaultroot         6     1  0 15:30 pts/0    00:00:00 ./signal_test

可以看到 signal_test 程序作为 docker-init 的子进程启动了。

在 docker stop 命令发送 SIGTERM 信号给镜像以后,docker-init 进程会将这个信号转给 signal_test,这个应用进程就可以收到 SIGTERM 信号做自定义的处理,比如优雅停机等。

除了 docker 的官方方案,Node.js 的最佳实践还推荐了一个 tini 这样一个 C 语言写的极小的 init 进程,github.com/krallin/tin… 。它的代码较短,很值得一读,对理解信号传递、处理僵尸进程非常有帮助。

小结

通过这篇文章,希望你可以搞懂僵尸进程、孤儿进程、PID 为 1 的进程是什么,以及为什么 node/npm 不适合做 PID 为 1 的进程,bash 作为 PID 为 1 的进程有什么缺陷。

下面留一个作业题,考考你对进程 fork 函数的理解。如下程序连续调用三次 fork() 调用后会产生多少新进程?

#include #include int main() {  printf("Hello, World!/n");  fork();  fork();  fork();  sleep(100);  return 0;}


免责声明:本站所有信息均搜集自互联网,并不代表本站观点,本站不对其真实合法性负责。如有信息侵犯了您的权益,请告知,本站将立刻处理。联系QQ:1640731186
友荐云推荐
热网推荐更多>>