简单描述下项目,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 确实已经很满了。
1
v2byy OP 还有个问题是,为什么生成的 profiling result 中会出现 node 的上一个 caller 还是 node 的情况?
``` ticks parent name 6579 45.7% /usr/local/bin/node 4237 64.4% /usr/local/bin/node 494 11.7% LazyCompile: *_onMessage /usr/local/src/myproject/src/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:87:21 480 97.2% LazyCompile: *_dispatch /usr/local/src/myproject/src/node_modules/puppeteer-core/lib/cjs/puppeteer/node/PipeTransport.js:40:14 263 54.8% Function: ^<anonymous> /usr/local/src/myproject/src/node_modules/puppeteer-core/lib/cjs/puppeteer/node/PipeTransport.js:25:67 123 46.8% LazyCompile: *addChunk node:internal/streams/readable:304:18 123 46.8% Function: ^emit node:events:474:44 17 6.5% LazyCompile: *readableAddChunk node:internal/streams/readable:236:26 ``` |
2
fuis 2022-04-28 20:22:14 +08:00
多给点资源不就完了?
|
4
number 2022-04-28 21:50:16 +08:00 via Android
同一时间只会开一个 chrome 吗,tab 有几个?
|