DTrace

Очень часто при наблюдении за производительностью системы важно знать не каждый конкретный случай, когда выполняется та или иная проба DTrace, а видеть общую картину . Например, наблюдая за каким-то процессом, поедающим процессорное время согласно prstat, мы задаём себе вопрос: а чем же занимается этот процесс? И часто под этим вопросом мы имеем в виду не конкретно каждый системный вызов, выполняемый процессом, а количество этих вызовов.

Агрегации DTrace как раз и созданы для ответов на подобные вопросы. Оперируя c числовыми наборами данных, агрегирующие функции помогают нам легко определять средние, максимальные и минимальные величины, подсчитывать количество и сумму элементов набора и распределения частот элементов.

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

DTrace хранит результаты выполнения агрегирующих функций в объектах, которые и называются агрегациями.

Синтаксис определения агрегации таков:
@name[ keys ] = aggfunc ( args );
здесь:
name - название нашей агрегации
keys - ключи-индексы агрегации, очень похожи на знакомые многим ключи ассоциативных массивом
aggfunc - агрегирующая функция
args - аргументы функции, обычно это числовой ряд

В сегодняшнем примере я использую агрегирующую функцию sum, которая, как видно из названия, вычисляет сумму элементов указанного числового ряда.

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

Для поверхностного анализа можно использовать меньше ключей для нашей агрегации - например, только pid, без указания thread'ов, или даже execname - но в этом случае следует помнить, что в системе может быть запущено более одного процесса с одним и тем же именем. Тем не менее, подобные агрегации помогают однозначно сказать, на что же тратится больше всего внимания:

Скрипт:


Сохраните этот код в файл, сделайте ему chmod a+x и запускайте. Получите примерно такой результат:




Время в последней таблице приведено в наносекундах, так что не пугайтесь таким огромным числам :) Для засекания времени во время выполнения скрипта очень удобно использовать приведённую в примере переменную timestamp. Это счётчик наносекунд, который начинает отсчёт с произвольного числа, и потому может применяться только для относительных подсчётов времени.

Вот тут-то и становится понятно, сколько всего ненужного происходит в секунду на моём лаптопе с запущенным Gnome ;)

Далее можно немного усложнить скрипт, и получится мощный инструмент для подробного анализа, кто, чем, и как долго занимался:



Сохранив этот код в файл syscalls.d и запустив этот скрипт, вы получите примерно следующий результат (дабы не засорять блог, я удалил часть строк):



Если оставить такой скрипт запущенным на пару минут, в результате получится длинный список, содержащий все процессы, запущенные в системе, со всеми системными вызовами, которые они выполняли, и с указанием времени, потраченного на эти вызовы каждым thread'ом.

Макро-переменные способны сильно упростить вашу жизнь при написании скриптов DTrace. Их имена начинаются со знака $, и при чтении вашего скрипта DTrace> автоматически заменит макро-переменные их соответствующими значениями.

Полный список макро-переменных можно прочесть здесь, а я рассмотрю в этот раз лишь одну из таких переменных: $target.

$target указывает на PID процесса, указанного в командной строке DTrace-скрипта.

DTrace имеет две полезных опции командной строки, которые вы можете указывать не только при использовании собственно команды dtrace, но и при вызове DTrace-скриптов:

./script.d -c xterm
Эта команда укажет на то, что DTrace следует выполнить указанную после ключа -c команду, и уже потом обработать текст DTrace-скрипта в файле script.d. При этом макро-переменная $target будет содержать PID процесса запущенной команды - xterm в нашем примере.

./script.d -p 654
Это аналогичный вариант выполнения DTrace скрипта, только вместо запуска команды мы лишь сообщаем DTrace, какой именно уже запущенный в системе процесс нас интересует. $target и будет содержать PID указанный в командной сроке.

Использовать макро-переменную $target можно следующим образом:



Если мы запустим этот скрипт как в первом примере, то получим примерно следующий результат:



Чуть позже я расскажу про агрегации - ещё одну замечательную возможность сбора данных в DTrace, и тогда можно будет приводить примеры скриптов поинтереснее ;)

Заглянул в очередной раз на BigAdmin: DTrace, и наткнулся снова на эту полезную ссылку - и решил-таки подчеркнуть её полезность.

Ссылка эта ведёт на pdf-файл с докладом трёх авторов DTrace - Bryan M. Cantrill, Michael W. Shapiro и Adam H. Leventhal на последней конференции USENIX. Называется этот документ так: Dynamic Instrumentation of Production Systems.
Помимо перечисления достоинств DTrace, дано довольно подробное концептуальное описание механизмов динамической отладки с помощью DTrace - так что очень рекомендую почитать.

Одна из самых полезных для меня возможностей в DTrace - это опция flowindent. Всё, что она делает - это отмечает вход в какую-нибудь функцию с помощью знаков "->", и выход из этой же функции знаками "<-". Казалось бы, что может быть проще - а вы только посмотрите, насколько приятнее выглядит результат!

Данный пример ловит все пробы провайдера fbt. В режиме по умолчанию (а мы будем находиться именно в нём, раз никакими опциями ничего не меняем кроме flowindent) DTrace регистрирует указанные пробы и выводит информацию, когда регистрация этих проб произошла.

Код скрипта:


И вот какой мы получаем результат:


Стоит лишь добавить к этому скрипту опцию flowindent (это, кстати, можно также сделать просто добавив -F как параметр командной строки), как ход исполнения кода становится гораздо понятнее:

Новый скрипт:


И результат:

В DTrace нет условных операторных скобок типа if..then..else, вместо них используются предикаты.
Предикат - это заключённые в слэши (/) условия, приводимые сразу после строки объявления той или иной пробы, и предназначенные для контроля за необходимостью выполнения кода, относящегося к этой пробе.

Скажем, следующий скрипт выведет список всех системных вызовов, кроме write, для всех процессов, запущенных на системе. Так как DTrace отслеживает события на уровне thread'ов, в примере запуска этого скрипта видно, что некоторые иднентификаторы процессов повторяются. Это потому что пробы сработали для различных thread'ов одного и того же процесса:



После запуска скрипта вы увидите примерно следующее:



Т.е. скрипт учёл и системные вызовы, выполненные командой dtrace, которая выполняла скрипт. Для того, чтобы исключить эту команду из нашей статистики, следует изменить предикат:


и тогда вывод команды будет включать уже все другие процессы, кроме dtrace, в моём примере это парочка моих терминалов rxvt и java:



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

Локальные для каждого thread'а переменные объявляются с помощью оператора -> специального идентификатора self, например: self->flag = 1;.

Приведённые ниже пример выведет лишь по одному сообщению про системный вызов write каждого из thread'ов всех процессов, выполняющих этот вызов. Как видно из кода, едва мы сообщаем об очередном thread'е, который мы уличили в завершении системного вызова write, мы тут же отмечаем в локальной для этого thread'а переменной, что он уже был обработан: self->processed = 1;. А предикат уже позаботится о том, чтобы в следующий раз для уже отмеченного thread'а мы не выполняли код нашей пробы:



Как видно, каждый thread был зарегистрирован только один раз:



Всех способов использования предикатов не расскажешь в одной записи, так что в следующий раз я постараюсь показать ещё несколько вариантов использования этой замечательной возможности DTrace.