如何获取正在运行的Node.js进程的线程转储？

Question

在Java JVM中，kill -3强制进程打印所有运行线程的当前堆栈跟踪，这对于快速定位瓶颈非常有效。是否存在V8的等效功能？我能否让V8打印当前堆栈跟踪？

澄清： 我假设由于Node的异步性质，它将比典型的非异步程序不那么有用。即使如此，如果有一种简单的方法可以访问几个堆栈跟踪，查看它也不需要花费太多时间。从我的经验来看，在需要切换到更高级工具之前，通过这种方式可以快速定位一些明显的瓶颈问题。

- Philipp Claßen

---

@PaulDraper 我不知道是不是只有我，但这个问题似乎假定其他人在使用 kill -3 JVM 时对 OP 的用例有一个公平的了解。我建议您提出一个编辑来获得适当的解决方案。 - Aditya Guru

@AdityaGuru 这里描述了一种想法（查看堆栈跟踪，有时称为穷人的分析器）：https://dev59.com/n3RC5IYBdhLWcg3wOOL1#378024 - Philipp Claßen

@AdityaGuru 一个类似的情况是调试“挂起”的程序。 - Paul Draper

所以要点是“它无法完成” - 至少不能针对已经运行的任意 NodeJS 进程，就像我们可以使用 kill -3 命令那样。 - Janaka Bandara

@JanakaBandara 我也这么认为。确实有一些方法可以识别NodeJs的性能问题，但它们在生产环境中不能像运行“kill -3”那样容易应用。 当我在生产环境中识别性能问题时，我的第一步是现在运行“perf top”。 有时它会给你一个线索，但明显存在缺点：它不理解NodeJs，因此输出可能很难解释。 另外，它监控CPU使用情况，因此对于IO绑定的进程来说可能会产生误导。 它仍然很容易运行，并且不会过多拖慢生产系统的速度，所以我首选它。 - Philipp Claßen

Answer 1

Node已经完全加载了诊断工具，就像上面提到的技巧一样（如果我理解正确的话）会变得多余，但请随意纠正我。 必读: NodeSource的精彩博客 1 2 3 我会尽力列出我发现有用的所有工具：

• 诊断报告

• v8分析器

• 火焰图

• 为什么node在运行

• 跟踪

• 澄清

其他（只是通过谷歌搜索到的）。

• N|NodeSource 的 Solid
• Autopsy
• StackImpact

- Aditya Guru

Answer 2

这个线程上有一个使用以下内容的想法：

# node --debug-brk buggy.js
Debugger listening on port 5858

在另一个终端中：

# node debug -p $(pgrep -f 'node.*buggy')
connecting to 127.0.0.1:5858 ... ok
break in buggy.js:16
 14 }
 15 
>16 z();
 17 
 18 });
debug> cont

等待节点进程开始使用100%的CPU。

debug> step
break in buggy.js:3
  1 function x() {
  2     var i = 0;
> 3     while(1) {
  4             i++;
  5     }
debug> bt
#0 buggy.js:3:8
#1 buggy.js:9:2
#2 buggy.js:13:2
#3 buggy.js:16:1

Source: https://github.com/nodejs/node-v0.x-archive/issues/25263

- zvi

---

注意：这里使用的是传统调试器。 - undefined

Answer 3

您可以使用 heapdump 工具来完成相同的操作。我发现以下文章介绍了相同的内容（它也对我有用）： https://medium.com/better-programming/make-a-dump-of-the-v8-heap-and-inspect-for-your-node-app-b69f7b68c162

- Viral Patel

---

请在此展示技术，而不是链接到收费墙后面的文章。 - metadaddy

我无法再阅读这篇文章了，因为Medium现在设置了付费墙。 - undefined