DTrace

Итак, открытие OpenSolaris.Org состоялось!

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

Bryan Cantrill сегодня добавил очень интересную запись в свой блог, советую почитать: Solaris 10 Revealed.

Очень часто при наблюдении за производительностью системы важно знать не каждый конкретный случай, когда выполняется та или иная проба 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 - так что очень рекомендую почитать.