профилирование nodejs; что может быть "неизвестным"

При профилировании программы nodejs я вижу, что 61% тиков вызваны "неизвестным" (см. ниже). Что же это может быть? Что я должен искать?

Gr,

Coen 

Statistical profiling result from node, (14907 ticks, 9132 unaccounted, 0 excluded).

 [Unknown]:
   ticks  total  nonlib   name
   9132   61.3%

 [Shared libraries]:
   ticks  total  nonlib   name
   1067    7.2%    0.0%  C:WindowsSYSTEM32ntdll.dll
     55    0.4%    0.0%  C:Windowssystem32kernel32.dll

 [JavaScript]:
   ticks  total  nonlib   name
   1381    9.3%   10.0%  LazyCompile: *RowDataPacket.parse D:MIpacket.js:9
......
3 5
node.js profiling v8

3 ответа:

Вы используете 64-разрядную версию Node.JS для запуска вашего приложения и 32-битная сборка оболочки d8 для обработки вашего v8.log. Используя либо 32-разрядную версию Node.JS с ia32 в качестве цели сборки для оболочки d8 или 64-разрядной версии Node.JS с x64 в качестве цели сборки оболочки d8 должен решить вашу проблему.

2

Загружаете ли вы какие-либо модули, имеющие встроенные зависимости?

В основном под " неизвестным "подразумевается" неучтенный " (проверьте tickprocessor.js для более подробного объяснения). Например, GC будет печатать сообщения типа " scavenge, begin,..."но это не признается logreader.js.

Было бы полезно узнать, какую библиотеку профилирования вы используете для анализа файла v8.log.

Обновить

Пакет node-tick не обновлялся более года и, вероятно, не хватает многих последних версий. prof команды. Вместо этого попробуйте использовать node-profiler. Он создан одним из сопровождающих узла. И если вы хотите получить абсолютно лучший результат, вам нужно построить его с помощью node-gyp.

Обновить

Я проанализировал вывод v8.log, используя последний из node-profiler (последний на master, а не последний тег) и опубликовал результаты в http://pastebin.com/pdHDPjzE

Позвольте мне указать на пару ключевых записей, которые появляются примерно на полпути. вниз: 

[GC]:
  ticks  total  nonlib   name
  2063   26.2%

[Bottom up (heavy) profile]
6578   83.4%  c:\node\node.exe
1812   27.5%    LazyCompile: ~parse native json.js:55
1811   99.9%      Function: ~<anonymous> C:\workspace\repositories\asyncnode_MySQL\lib\MySQL_DB.js:41
 736   11.2%    Function: ~Buffer.toString buffer.js:392

Таким образом, 26,2% всего типа скрипта было потрачено на сборку мусора. Что намного выше, чем должно быть. Хотя это хорошо коррелирует с тем, сколько времени тратится на Buffer.toString. Если такое количество буферов создается, а затем преобразуется в строки, оба должны быть GCD, когда они покидают область видимости.

Также мне любопытно, почему так много времени тратится в LazyCompile для json.js. Или более того, зачем json.js вообще нужно в узловом приложении?

Чтобы помочь вам производительность настройка вашего приложения я включаю несколько ссылок ниже, которые дают хорошие инструкции о том, что делать и искать.

Хорошая слайд-дека с основами:
https://mkw.st/p/gdd11-berlin-v8-performance-tuning-tricks/#1

Более продвинутые примеры оптимизации techniques:
http://floitsch.blogspot.com/2012/03/optimizing-for-v8-introduction.html

Лучшее использование затворы:
http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html

Теперь о том, почему вы не смогли достичь того же результата. Если вы построили и использовали node-profiler и его предоставленный nprof из master, и он все еще не работает, то я предположу, что это как-то связано с тем, что он находится в Windows. Подумайте о том, чтобы установить ошибку на GitHub и посмотреть, поможет ли он вам.
2

Попробуйте построить v8 с поддержкой профилирования на: 

scons prof=on d8

Убедитесь, что вы запускаете node --prof с версией, соответствующей версии v8

Затем tools/linux-tick-processor path/to/v8.log должен показать вам полную информацию о профиле.

0