我正在运行 nodejs 4.4.7 LTS

我按照此处 https://nodejs.org/en/docs/guides/simple-profiling/ 的说明运行分析器:

node --prof app.js

然后:

node --prof-process isolate-something-v8.log > processed.txt

我错过了探查器的东西吗？

代码是关于什么的:

NodeJS 应用程序是 socket.io 服务器将数据从 WEB 发送到 C++ 应用程序，反之亦然。

您可以从下面的结果中看到，这里有大量未计入的抽动。在这种情况下，什么可能导致这种情况以及如何知道我的应用程序的瓶颈是什么？有什么解决办法？

Code move event for unknown code: 0x61047523c0
Code move event for unknown code: 0x6104bf74a0
Statistical profiling result from isolate-000001E1507CF2D0-v8.log,     (211705 ticks, 210634 unaccounted, 0 excluded).

 [Shared libraries]:
   ticks  total  nonlib   name

 [JavaScript]:
   ticks  total  nonlib   name
     71    0.0%    0.0%  LazyCompile: *stringToBuffer *SOMETHING*\socket.io\node_modules\engine.io\node_modules\engine.io-parser\lib\index.js:359:24
     59    0.0%    0.0%  LazyCompile: listOnTimeout timers.js:56:23
     50    0.0%    0.0%  LazyCompile: *wrapper timers.js:274:19
     43    0.0%    0.0%  Stub: StringAddStub_CheckNone_NotTenured

    .
    .
    .


[C++]:
   ticks  total  nonlib   name

 [Summary]:
   ticks  total  nonlib   name
   1071    0.5%    0.5%  JavaScript
      0    0.0%    0.0%  C++
    202    0.1%    0.1%  GC
      0    0.0%          Shared libraries
  210634   99.5%          Unaccounted

 [C++ entry points]:
   ticks    cpp   total   name

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 2.0% are not shown.

   ticks parent  name
  210634   99.5%  UNKNOWN

最佳答案

始终更新到您正在使用的任何软件的最新稳定版本，Node.js 4.4.7 已经有几年的历史了。

“Node.js - a tale of two bugs”中的 Mike Ralphson 博客:

"It is important to run both commands with exactly the same version of Node.js.

Unfortunately, when I tried to profile converting a single file (which showed around a 100% increase in execution time), both Node.js 7.x and v8.0.0-test20170511830c4bf319 showed almost all the time as unaccounted: ...

Having exhausted my Node.js debugging skills, I asked what I could do to try and produce a minimal test-case, and if there were any major anti-patterns which could result in much worse performance in Node.js 7 and 8.

I was at this stage convinced that the problem lay either in ajv (the library used to validate JSON schemas in swagger2openapi) or should.js (the BDD test/assertion library I was using).

Ben Noordhuis 补充说，以下命令将提供更深入的分析信息，特别是哪些功能被取消优化，以及原因:

 $ node8 --trace_opt --trace_deopt swagger2openapi petstore.json 

This pointed to two lines within should.js:

 ;;; deoptimize at <D:\nodejs\swagger2openapi\node_modules\should\cjs\should.js:152:14>, no cache

 ;;; deoptimize at <D:\nodejs\swagger2openapi\node_modules\should\cjs\should.js:68:14>, no cache 

That helped narrow it down, and I soon came up with a minimal test-case which showed the regressed behaviour.

 var should = require('should'); //11.2.0

 for (var i=0;i<10000;i++) {
     i.should.not.be.type('string');
 }

Node.js contributor Anna Henningsen reported that this was reproduceable.

...

He also offered to try and back-port the fix into v8 6.0 so it could be included in the current release stream of Node.js. This effort appears to have stalled however, but the good news is that the fix is already in the nightly builds of Node.js 9.0, which include v8 6.1.

The plan was to release Node.js 8.7 with v8 6.1, which should have fixed all my problems, however, a problem has been found with the v8 escape analysis which has had to be disabled in Node.js 8.7 - potentially making this release not as fast as I'd hoped. Whether the fix from v8 6.2 will make it into Node.js 8.x before it goes LTS (Long Term Support) is still a matter of conjecture, but I leave you with the comparative timings from my use-case for Node.js 6.11.4, 8.6.0, 8.7.0 and 9.0.0-nightly.

...

If you're using an exception-based assertion tool in your development environment, or any performance-critical code which depends on thrown error stack-traces, or just wondered where your performance went since Node.js 6.x, you should definitely consider upgrading to Node.js 8.7.

• 更新您的工具链和 Nodejs。

• 制作一个最小的测试用例来证明是否存在错误。

• 阅读您正在使用的软件的错误报告、博客和已知问题。

我之前在 gcc 上遇到过类似的问题，未知并且没有深入到共享库中，我使用详细调试 (-ggdb IIRC) 重新编译了我的整个工具链，所以我可以看到所有内容。剥离很容易去除多余的。这个特殊的解决方案对我很有用，因为我参与了测试和错误报告，可能对普通用户没有用，尽管它很容易拥有多个版本的工具链。

关于node.js - nodejs分析未知和下落不明的结果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38145769/