Ответ 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 для двух версий узла?
Надеюсь, что это поможет, и надеюсь, что я прав,
С наилучшими пожеланиями