Ужасная производительность при обновлении с узла v6.7.0 до v8.11.1

Я провел последние несколько дней, исследуя низкую производительность для приложения api-приложения graphsl api при обновлении узла с v6.x до v8.x.

Я взял много графиков пламени, но я не могу понять, где это узкое место. Кто-нибудь знает, что такое ___kdebug_trace_string (в c++)? Похоже, что после обновления у меня появляется гораздо больше времени.

Посмотрите этот график пламени:

Flame graph

Также проверьте эти журналы профилей:

узел профиля v8.x (медленный): https://pastebin.com/2W65BZC8

Журнал профиля узла v6.x: https://pastebin.com/BL4kM7B7

Спасибо, вперед!

ОТВЕТЫ

Ответ 1

kdebug_trace_string - это syscall, который был добавлен в XNU в октябре 2015 года для iOS 9 и OS X 10.11.

Это часть kdebug, основной встроенной системы отладки XNU. При чтении kdebug_trace.c в комментариях я нашел следующее примечание:

Обратите внимание, что API-интерфейс пользовательского пространства позволяет оптимизировать скорость, не-ошибка производительности путем проверки валидации каждого debugid. Это означает, что случаи ошибок, которые могли быть пойманы в пользовательском пространстве, сделают системный вызов перед возвратом с правильным кодом ошибки. Этот компромисс в производительности преднамерен.

Это объясняет, почему ___kdebug_trace_string занимает так много места на вашем графике пламени.

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


Предполагая, что я прав, если kdebug_trace_string, значит, это узел запускает какую-то утилиту для отладки. Я загрузил node-v8.11.1-darwin-x64 и нашел следующую строку в node/config.gypi:

 'node_use_dtrace': 'true',

Поэтому узел v8.11.1 использует dtrace.
Затем, рассматривая эту строку в osx/src/dtrace/libdtrace/dt_open.c, мы можем предположить, что dtrace использует kdebug_trace_string

Поэтому, чтобы исправить это, нужно было бы запретить узлу использовать dtrace. В соответствии с этим ответом: "Когда Node запускается, файл.gypi загружается, как и любой другой файл настроек". Так что, возможно, вам стоит установить node_use_dtrace в false

НО

Я не понимаю, почему вы не столкнулись с той же проблемой с узлом v6.7.0:

  • В node-v6.7.0-darwin-x64 значение node_use_dtrace равно true
  • Узел v6.7 прибл. дата выпуска: 2016-09-28
  • OS X 10.11 приблизительная дата выпуска: 2015-09-06

Не могли бы вы рассказать мне значение node_use_dtrace для двух версий узла?

Надеюсь, что это поможет, и надеюсь, что я прав,
С наилучшими пожеланиями