简单描述下项目,container 里面 nodejs 进程启动一个 web server ,同时会用到 puppeteer 控制 chrome 做些事情。
遇到的问题是 container 经常会因为 liveness probe fail 被 restart 。其中 liveness probe 直接就是做的 webserver 简单的 health check 。所以确实是 CPU 使用太高,导致 eventloop 被 block ,无法响应 liveness check 。
使用 node 内建的 profile 来做分析。
node --prof index.js
得到的结果是:
[Summary]:
ticks total nonlib name
420 2.9% 99.3% JavaScript
0 0.0% 0.0% C++
597 4.1% 141.1% GC
13981 97.1% Shared libraries
3 0.0% Unaccounted
[Shared libraries]:
ticks total nonlib name
6579 45.7% /usr/local/bin/node
5776 40.1% /lib/x86_64-linux-gnu/libc-2.28.so
1539 10.7% /lib/x86_64-linux-gnu/libpthread-2.28.so
82 0.6% /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
5 0.0% [vdso]
显示 CPU 是花在 node 上和 libc 里面的函数。 其中一些 callstack 是这样的
看 callstack 大部分时间都是 puppeteer 做 IPC ,也即 node 进程与 chrome 进程通信。
按理来说应该是异步的,不应该 block eventloop 。
有没有可能是libuv 里面 epoll_pwait 的时候 io callback 太多,导致迟迟无法进入到下一个 eventloop 导致 eventloop 被 block 了呢?发现问题的时候 container CPU 确实已经很满了。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.