Если я использую gcore для создания дампа кода процесса Node.js, какие лучшие инструменты для его анализа?
Вдохновленный: Инструмент для анализа дампа ядра Java
В моем конкретном случае я заинтересован в расследовании утечек памяти, поэтому мне очень любопытно получить некоторый анализ кучи. Также приветствуются общие инструменты и даже комплекты инструментов и техники. Я нахожу Node.js, чтобы быть очень интересным, но инструменты анализа времени исполнения просто не существуют.
Для расследования сбоев я нашел node-segfault-handler, чтобы быть бесценным. Это модуль, который я приготовил, чтобы получить трассировку стека собственного кода в случае жесткого сбоя с сигналом - например, deref из NULL, ведущего к SIGSEGV
Для изучения проблем с памятью/распределением, здесь некоторые из данных, которые я собрал до сих пор:
1) Запись в блоге Dave Patheco - автор рассказывает об использовании плагина для MDB для получения стеков JS и т.д. К сожалению, насколько я могу судить, источник этого плагина никогда не выпускался (ни какая-либо двоичная форма).
2) Отладка откликов в динамических средах - статья очереди ACM, также написанная Дейвом Патеко (связанная с сообщением в блоге). В то время как это делает для БОЛЬШОГО фонового чтения, статья не содержит в себе много конкретных инструментов и методов.
3) node-panic - инструмент чистого JS для сброса состояния в случае сбоя типа assert-failure. Ничего не помогает отлаживать сбои, возникающие из-за внутренних ошибок кода (SIGSEGV и т.д.)
4) Joyent: Отладка производственных систем - поговорите с Брайаном Кэнтрил о инструментах и техниках, которые он рекомендует (спасибо crickeys).
В Linux и Mac вы можете использовать llnode плагин для отладчика lldb. Проект доступен в организации nodejs на github:
https://github.com/nodejs/llnode
Вы можете установить из источника через github или использовать brew на Mac. Чтение на github должно помочь вам установить его, и здесь есть вводная статья в блоге:
Первоначальный вопрос состоял в анализе памяти, и команды v8 findjsobjects и v8 findjsinstances помогут там, создав базовую гистограмму подсчетов объектов и позволяя вам перечислять экземпляры каждого типа.
Здесь есть полная статья об использовании llnode для анализа памяти: http://www.brendangregg.com/blog/2016-07-13/llnode-nodejs-memory-leak-analysis.html
Обновление 2017: Теперь вы можете использовать решение @h-hellyer (llnode, основанное на lldb, а не на mdb). fooobar.com/info/371215/...
mdb + mdb_v8 - путь.
Чтобы использовать mdb, вам понадобится поддерживаемая ОС.
Теперь, скорее всего, вы будете работать в Linux. Если это ваш случай:
Вы можете получить свой основной дамп разными способами. Чтобы получить основной дамп из работающего процесса, вы можете сделать это:
pgrep -lf node # get pids
gdb -p your_pid
# once in gdb..
gcore # this will output your core dump
detach # this will allow the process to continue to run.
Есть вероятность, что вы знаете о Solaris, OpenSolaris, IllumOS или SmartOS. Скорее всего, это не так. Если вы можете позволить себе время настройки SmartOS и mdb_v8, отлично.
Если нет, установите VirtualBox, а затем autopsy. Это обрабатывает ритуал установки SmartOS, а также загружает ваши основные файлы дампа в виртуальную машину.
Как только вы закончите, и когда вы находитесь в своем сеансе mdb, вы можете выполнить некоторые шаги из этой .