Solaris 10: советы и приёмы системного администрирования - DTrace

Новый вебсайт: DTrace Scripts

nospam@example.com (Gleb Reys) — Fri, 09 Nov 2007 14:53:56 +0300

Через вебсайт CurThread.org я недавно узнал о новом онлайн проекте: DTrace Scripts. Похоже на проект создания постоянно развивающейся коллекции скриптов и советов для DTrace, так что очень приятно видеть очередной проект, делающий эту замечательную технологию более известной и доступной в Unix кругах.

Хорошая статья по DTrace

nospam@example.com (Gleb Reys) — Wed, 08 Feb 2006 16:32:11 +0300

Благодаря Адаму Левенталю, одного из авторов DTrace, я узнал о недавней статье про DTrace, написанной Брайаном Кантриллом.

Статья мне очень понравилась, так что немедленно добавил её в мой индекс ресурсов по DTrace.

Сама статья доступна по этой ссылке: Hidden in Plain Sight

Полезные ресурсы по DTrace

nospam@example.com (Gleb Reys) — Fri, 27 Jan 2006 13:06:14 +0300

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

Данная коллекция ссылок находится по этому адресу: http://solaris.reys.net/dtrace

DTrace: игры с mod_auth_pam и Apache 2

nospam@example.com (Gleb Reys) — Wed, 21 Dec 2005 13:29:25 +0300

Один из пользователей попросил помочь ему с настройкой PAM аутентификации в Apache 2, на одном из наших удалённых серверов.

Казалось бы, простая до безобразия задача - скачать mod_auth_pam, скомпилировать его для Apache 2, и проверить, что всё работает. Система использует NIS, потому что я на неё смог запросто зайти.

И что же? Не тут-то было! Модуль скомпилировался запросто, но работать отказывался - в error_log'е упорно появлялись следующие строки (я разбил строку на двое, а то портится общий вид блога):

CODE:

[Tue Dec 20 16:48:44 2005] [error] [client xxx.xxx.xxx.xxx] \
PAM: user 'greys' - not authenticated: No account present for user

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

1) Перевести эксперименты с системы пользователя на свой Solaris 10-бокс.
2) Для начала отладить процедуру для локальных пользователей, а уже потом браться за NIS

Увидев аналогичные ошибки на своей системе, я решил всерьёз взяться за PAM. Завёл строки в /etc/pam.conf специально для Apache, и добавил к ним опцию debug:

CODE:

httpd auth required pam_authtok_get.so.1 debug
httpd auth required pam_unix_auth.so.1 debug

Чтобы удобнее ловилась отладочная информация, подправил /etc/syslog.conf, чтобы он включал следующие строки:

CODE:

auth.debug /var/log/auth_log
user.debug /var/log/user_log

После этого стало удобнее наблюдать, что же именно происходит - по крайней мере, было ясно, что исполняется как раз та часть /etc/pam.conf, которая и была нужна. Но ошибка по-прежнему вводила меня в тупик - пользователь явно существовал, но Apache'м упорно не распознавался (опять приходится переносить строки, чтобы общий вид блога не портился):

CODE:

Dec 21 09:47:35 pele httpd[29143]: [ID 634615 user.debug] \
pam_authtok_get:pam_sm_authenticate: flags = 1
Dec 21 09:47:35 pele httpd[29143]: [ID 378613 user.debug] \
pam_dhkeys: user greys not found
Dec 21 09:47:35 pele httpd[29143]: [ID 896952 user.debug] \
pam_unix_auth: entering pam_sm_authenticate()
Dec 21 09:47:35 pele httpd[29143]: [ID 219349 user.debug] \
pam_unix_auth: user greys not found

Настал момент посмотреть, что же именно делают PAM и Apache 2, когда я ввожу запрашиваемые имя пользователя и пароль для доступа к странице. Тут я сразу вспомнил про замечательный скрипт opensnoop от товарища Брэндана Грэгга (Brendan Gregg). И данный скрипт, запущенный в отдельной консоли, тут же помог мне увидеть, в чём была проблема:

CODE:

60001 24744 httpd         -1   2 /etc/pam_debug
60001 24744 httpd         11   0 /etc/pam.conf
60001 24744 httpd         11   0 /usr/lib/security/pam_authtok_get.so.1
60001 24744 httpd         11   0 /usr/lib/passwdutil.so.1
60001 24744 httpd         11   0 /usr/lib/libsldap.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_dhkeys.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_unix_cred.so.1
60001 24744 httpd         11   0 /lib/libbsm.so.1
60001 24744 httpd         11   0 /lib/libsecdb.so.1
60001 24744 httpd         11   0 /usr/lib/libproject.so.1
60001 24744 httpd         11   0 /lib/libproc.so.1
60001 24744 httpd         11   0 /lib/librtld_db.so.1
60001 24744 httpd         11   0 /lib/libelf.so.1
60001 24744 httpd         11   0 /lib/libctf.so.1
60001 24744 httpd         11   0 /usr/lib/security/pam_unix_auth.so.1
60001 24744 httpd         -1   2 /var/run/syslog_door
60001 24744 httpd         -1  13 /etc/shadow
60001 24744 httpd         11   0 /var/run/name_service_door
60001 24744 httpd         11   0 /etc/passwd
60001 24744 httpd         -1  13 /etc/shadow
60001 24744 httpd         -1   2 /var/run/syslog_door

Как видно, httpd не мог открыть файл /etc/shadow (ошибка - код -1), естественно из-за ошибки доступа. Но на всякий случай это можно было проверить. Второй номер в строке про /etc/shadow - это 13, код ошибки:

CODE:

bash-3.00# grep 13 /usr/include/sys/errno.h
#define EACCES 13 /* Permission denied */

Ну и после этого всё уже было делом техники:

CODE:

#groupadd shadows
# chown root:shadows /etc/shadow
# chmod 440 /etc/shadow

И осталось указать в httpd.conf, чтобы Apache запускался как раз под этой группой, а не под nobody.

pS: а изначально это всё не работало на машине с NIS-доступом, потому что там в /etc/nsswitch.conf было написано не passwd: files nis, а passwd: compat, и всё использование NIS'а было сделано с помощью указания групп с помощью + и - в файлах /etc/passwd и /etc/shadow. Т.е. доступ на чтение /etc/shadow всё равно нужен, хотя реально потом это и будет обращение к NIS.

DTrace: наблюдение за PHP, часть 2

nospam@example.com (Gleb Reys) — Tue, 13 Dec 2005 02:16:13 +0300

Следующим шагом наблюдения за PHP с помощью DTrace вполне может стать подобный скрипт. Он подсчитывает, сколько наносекунд провёл процесс Apache, выполняя ту или иную функцию PHP.

В ходе работы, скрипт выводит таблицу процессов Apache и скриптов PHP, в них запускаемых. Позже выводится таблица всех функций, с указанием процесса, который их выполнял, и затраченного времени.

Скрипт можно скачать тут: php-scripts-timer.d

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

BEGIN
{
printf("php scripts timer started\n");
}

:dtrace.so::function-entry
/ copyinstr(arg0) == "" && name[pid,copyinstr(arg1)] != 1 /
{
        printf("%d -> %-30s\n", pid, copyinstr(arg1));
        name[pid,copyinstr(arg1)] = 1;
}

:dtrace.so::function-entry
/ copyinstr(arg0) != "" /
{
        self->ts = timestamp;
}

:dtrace.so::function-return
/ copyinstr(arg0) != "" /
{
        self->elapsed = timestamp - self->ts;
        @time[pid, copyinstr(arg0)] = sum(self->elapsed);
}

END
{
        printf("<------ php scripts timer finished");
        printf("\n%10s %40s %14s\n", "PID", "PHP function", "Time elapsed");
        printa("%10d %40s %14@u\n", @time);
}

А вот так может выглядеть типичный результат запуска этого скрипта, при параллельно открываемых с вашего сервера страниц с PHP:

CODE:

php scripts timer started
223074 -> /export/www/nightly/pma/left.php
223071 -> /export/www/nightly/pma/main.php
223074 -> /export/www/nightly/pma/css/phpmyadmin.css.php
223071 -> /export/www/nightly/pma/css/phpmyadmin.css.php

<------ php scripts timer finished
       PID                             PHP function   Time elapsed
    223074                             ob_get_level          22280
    223074                              get_cfg_var          32678
    223074                    mysql_get_client_info          32705
    223074                                  strrpos          39160
    223074                        PMA_auth_set_user          39178
    223071                     get_magic_quotes_gpc          39478
    223071                             ob_get_level          43673
    223071                               addslashes          54847
    223074                                   strpos          56869
    223071                                 basename          61874
    223071                     PMA_reloadNavigation          63588
    223071                    mysql_get_client_info          64570
    223071                              get_cfg_var          64592
    223071                             ereg_replace          65993
    223074                     get_magic_quotes_gpc          67738
...
    234950                                     main       84254684
    238255                                     main      105016748
    238255                                   substr      153752861
    238255                              mysql_query      192585647
    238255                        PMA_DBI_try_query      195113800
    234950                            PMA_DBI_query      220108343
    234950                              mysql_query      276732073
    234950                        PMA_DBI_try_query      280801228

DTrace: наблюдение за PHP

nospam@example.com (Gleb Reys) — Tue, 06 Dec 2005 20:16:23 +0300

Наконец-то нашёл время, и скачал PEAR модуль DTrace. Замечательная штука! Нашёл там одну маленькую проблему, и написал письмо товарщиу Фёрлонгу (Wez Furlong), который немедленно внёс изменения в исходник модуля, и теперь всё работает просто замечательно. Большущее спасибо, Wez! :)

Итак, самый первый скрипт для наблюдения за PHP: php-scripts-snoop.d

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

:dtrace.so::function-entry
/ copyinstr(arg0) == "" /
{
printf("%d -> %-30s\n", pid, copyinstr(arg1));
}

:dtrace.so::function-return
/ copyinstr(arg0) == "" /
{
printf("%d <- %-30s\n", pid, copyinstr(arg1));
}

Качайте скрипт, ставьте ему chmod a+x, и после запуска его в терминале на вашем веб-сервере, можно запускать различные скрипты PHP с этого сервера, и скрипт будет докладывать, когда начинается или заканчивается выполнение того или иного PHP скрипта, и который из процессов Apache за это отвечает:

CODE:

bash-3.00# ./php-scripts-snoop.d
204934 -> /export/www/pma/index.php
204934 <- /export/www/pma/index.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204936 -> /export/www/pma/left.php
204934 -> /export/www/pma/queryframe.php
204936 <- /export/www/pma/left.php
204936 -> /export/www/pma/main.php
204934 <- /export/www/pma/queryframe.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204934 -> /export/www/pma/css/phpmyadmin.css.php
204936 -> /export/www/pma/css/phpmyadmin.css.php
204934 <- /export/www/pma/css/phpmyadmin.css.php
204934 -> /export/www/1.php
204934 <- /export/www/1.php
204936 <- /export/www/pma/css/phpmyadmin.css.php

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

DTrace: параметры командной строки в скриптах

nospam@example.com (Gleb Reys) — Wed, 18 May 2005 20:05:49 +0400

При написании скриптов DTrace, часто вам нужно передать скрипту какой-нибудь параметр в командной строке. Эта простая задача может быть неожиданно трудной, если не прочесть раздел docs.sun.com про написание скриптов на DTrace, особенно раздел про макросы параметров командной строки.

Как и в оболочках sh и bash, вы можете получить значения параметров командной строки с помощью макросов $0..$9. Но тут есть одно "но". Значения параметров должны попадать под определенный тип - число, имя идентификатора или строку. Если переданный параметр не попадает под одно из этих определений, будет выдана ошибка.

Давайте начнём с простенького скрипта.

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet

BEGIN {
printf("Your parameter: %d\n", $1);
}

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

Но если попробовать передать строчку вместо числа, выйдет следующее:

bash-3.00# ./args.d a1b2c3
dtrace: failed to compile script ./args.d: line 9: failed to resolve a1b2c3: Unknown variable name

Это происходит потому, что DTrace пытается найти идентификатор "a1b2c3". Почему так происходит? Это из-за особенностей определения типа параметра. Значение не похоже на число, а из-за того, что мы передали строку без кавычек, DTrace считает, что это не строка. Единственный остающийся вариант - это идентификатор. Переменной с таким именем в скрипте нет, и потому мы получаем ошибку.

Чтобы проверить эту теорию, можно просто создать переменную с таким же именем в скрипте:

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet

BEGIN {
a1b2c3=1979;
printf("Your parameter: %d\n", $1);
}

Пожалуйста - всё работает именно так, как я сказал:

Your parameter: 1979

И если параметр у вас - точно строчка, то нужно изменить скрипт (чтобы printf печатал строку %s, а не целое число %d, иначе и тут будет ошибка)...

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet

BEGIN {
a1b2c3=1979;
printf("Your parameter: %s\n", $1);
}

... и передать строку, заключив её в кавычки, вот так:

bash-3.00# ./args.d '"a1b2c3"'
Your parameter: a1b2c3

Как вы видите, теперь мы действительно передаём и обрабатываем наш параметр как строку, а одноимённая переменная, специально оставленная в скрипте, больше не используется, иначе было бы выведено её значение.

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

CODE:

#!/usr/sbin/dtrace -s

#pragma D option quiet

BEGIN {
a1b2c3=1979;
printf("Your parameter: %s\n", $$1);
}

И вот как можно будет передавать строки такому скрипту:

bash-3.00# ./args.d a1b2c3
Your parameter: a1b2c3

Ну вот и всё на сегодня... Удачи с вашими скриптами DTrace!

Советы и приёмы эффективной работы от создателей DTrace

nospam@example.com (Gleb Reys) — Tue, 01 Mar 2005 13:38:04 +0300

Вчера Bryan Cantrill (один из создателей DTrace) выложил презентацию с полезными советами и приёмами работы с DTrace, а также упоминанием подводных камней, на которые легко нарваться не только новичкам, но и тем, кто уже какое-то время активно использует DTrace.

Как и оговаривается в начале презентации, часть вещей довольно проста - советы, это по большей части то, что многие могли бы знать, если бы второй раз перечитали документацию, а вот приёмы работы - очень даже полезные. Узнал много нового, и потому советую всем интересующимся тоже прочитать эту презентацию. Ссылка на PDF файл.

DTrace: провайдер pid

nospam@example.com (Gleb Reys) — Sat, 26 Feb 2005 23:52:58 +0300

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

Для начинающих работу с DTrace - это вполне приемлемая тактика. Но есть и более правильный способ: использование провайдера pid.

Как говорится в официальном руководстве, провайдер pid - это на самом деле не просто провайдер DTrace, а целый класс провайдеров. Как видно из названия, он предлагает нам пробы, относящиеся к конкретному процессу.

Скажем, провайдер pid737 предоставляет возможность следить за процессом с pid=737, и т.д. Более того - становится гораздо удобнее не только выделять интересующие нас пробы, но и понимать, на основе каких функций они создаются для каждого процесса.

Такой способ отладки конкретного процесса, в отличие от пробы с использованием предиката типа /pid == $target/, является более правильным. Вместо того, чтобы указанные пробы активизировались и предикат проверялся для каждого процесса, теперь DTrace и смотреть не станет на другие процессы - и лишь только для одного, нужного нам, и будут активированы указанные пробы. Переменную $target по-прежнему можно и даже нужно использовать при создании наших проб с использованием провайдера pid.

Мы уже знаем, как получить список проб, доступных DTrace. Я об этом уже рассказывал здесь. Так вот, стоит нам лишь один раз использовать провайдер pid для какого-то процесса, как dtrace -l начнёт нам показывать пробы, динамически созданные для него. Если процесс завершит работу, соответствующий провайдер исчезнет из списка доступных проб.

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

Вот маленький примерчик. Берём самую обычную Hello, world! программку на C:

CODE:

void main() {
printf("Hello, world!\n");
}

После того, как мы получили исполняемый файл, принимаемся за наш очередной DTrace-скрипт:

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

BEGIN {
printf("Target pid: %d\n", $target);
}

pid$target:::entry {
printf("%s:%s:%s:%s\n", probeprov, probemod, probefunc, probename);
}

Сохраняем скрипт, делаем этот файл исполняемым, и запускаем его, указывая в параметре нашу hello:

CODE:

$ ./pid-global.d -c ./hello | more
Target pid: 1059
Hello, world!
pid1059:LM1`ld.so.1:call_array:entry
pid1059:LM1`ld.so.1:call_init:entry
pid1059:LM1`ld.so.1:leave:entry
pid1059:LM1`ld.so.1:fmap_setup:entry
pid1059:LM1`ld.so.1:munmap:entry
pid1059:LM1`ld.so.1:rt_bind_clear:entry
pid1059:LM1`ld.so.1:_rt_bind_clear:entry
pid1059:LM1`ld.so.1:rt_mutex_unlock:entry
pid1059:LM1`ld.so.1:_rt_null:entry
pid1059:LM1`ld.so.1:rt_bind_clear:entry
pid1059:LM1`ld.so.1:_rt_bind_clear:entry
pid1059:libc.so.1:libc_init:entry
pid1059:libc.so.1:__amd64id:entry
pid1059:libc.so.1:atexit:entry
pid1059:libc.so.1:lmalloc:entry
pid1059:libc.so.1:getbucketnum:entry
...

Длинный список получится, почти 1000 строк - так что все показывать не буду, но идея, надеюсь, понятна. Видно, какие функции каждой библиотеки можно отследить средствами DTrace.

Очевидным будем из всего этого списка воспользоваться пробой, которая поймает наш printf:

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

BEGIN {
printf("Target pid: %d\n", $target);
}

pid$target::printf:entry {
printf("%s:%s:%s:%s\n", probeprov, probemod, probefunc, probename);
printf("Argument: %s\n", copyinstr(arg0));
}

Если запустить этот скрипт и передать ему нашу hello, как и в первом примере, то получится вот что:

CODE:

$ ./pid-printf.d -c ./hello
Target pid: 1201
Hello, world!
pid1201:libc.so.1:printf:entry
Argument: Hello, world!

Релиз исходного кода DTrace

nospam@example.com (Gleb Reys) — Tue, 25 Jan 2005 19:49:17 +0300

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

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

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

DTrace: агрегирующие функции (агрегации)

nospam@example.com (Gleb Reys) — Wed, 12 Jan 2005 19:26:30 +0300

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

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

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

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

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

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

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

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

Скрипт:

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

syscall:::entry
{
self->ts=timestamp;
}

syscall:::return
{
self->elapsed = timestamp - self->ts;
@time[execname]=sum(self->elapsed);
}

END
{
        printf("\n%20s %20s\n",
"Execname", "Time elapsed");

        printa("%20s %20@u\n", @time);
}

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

CODE:

     Execname         Time elapsed
        xscreensaver                 5710
       gnome-smproxy                 6886
         wnck-applet                 7735
         gnome-panel                52032
            metacity                54430
    gnome-settings-d                60419
                 vim                66452
       mixer_applet2            670078802
    gnome-netstatus-            819836799
            nautilus            900025830
                Xorg           1074783431
      gnome-terminal           1074816530
         firefox-bin           2000076871
              dtrace        9843796821648

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

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

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

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

syscall:::entry
{
self->ts=timestamp;
}

syscall:::return
{
self->elapsed = timestamp - self->ts;
@time[execname,probefunc,pid,tid]=sum(self->elapsed);
}

END
{
printf("\n%20s %20s %8s %7s %20s\n",
"Execname", "Syscall", "Process", "Thread", "Time elapsed");
printa("%20s %20s %8d %7d %20@u\n", @time);
}

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

CODE:

  Execname              Syscall  Process  Thread         Time elapsed
       gnome-terminal                 read     7199       1                12867
                Xorg                 read     6953       1                13769
              dtrace                  brk     7331       1                33647
              dtrace             schedctl     7331       1                39320
      gnome-terminal                write     7199       1                48052
                Xorg               writev     6953       1                57112
      gnome-terminal              pollsys     7199       1               646816
              dtrace             lwp_park     7331       1             44817217
                Xorg              pollsys     6953       1             46936244
              dtrace                ioctl     7331       1        9269224066655

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

DTrace: Макро-переменная $target

nospam@example.com (Gleb Reys) — Fri, 07 Jan 2005 18:34:22 +0300

Макро-переменные способны сильно упростить вашу жизнь при написании скриптов 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 можно следующим образом:

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

syscall:::entry, syscall:::return
/pid == $target/
{
printf("%d/%d: %s:%s\n", pid, tid, probefunc, probename);
}

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

CODE:

./script.d -c xterm
26525/1: munmap:entry
26525/1: munmap:return
26525/1: mmap:entry
26525/1: mmap:return
26525/1: setcontext:entry
26525/1: setcontext:return
26525/1: getrlimit:entry
26525/1: getrlimit:return
26525/1: getpid:entry
26525/1: getpid:return
...

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

Подробности о том, как работает DTrace

nospam@example.com (Gleb Reys) — Thu, 06 Jan 2005 01:12:57 +0300

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

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

Опции DTrace: flowindent

nospam@example.com (Gleb Reys) — Tue, 14 Dec 2004 19:26:42 +0300

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

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

Код скрипта:

CODE:

#!/usr/sbin/dtrace -s

fbt:::
/execname == "dtrace"/
{
}

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

CODE:

dtrace: script './try5.d' matched 32659 probes
CPU     ID                    FUNCTION:NAME
  1   2027                    xc_sync:entry
  1    819                 xc_do_call:entry
  1   1210         mutex_vector_enter:entry
  1   1238               lock_set_spl:entry
  1   2353                       splx:entry
  1  15484                apic_setspl:entry
  1  15485               apic_setspl:return
  1   2354                      splx:return
  1   1239              lock_set_spl:return
  1   1211        mutex_vector_enter:return
  1    821                  xc_common:entry
  1  15510              apic_send_ipi:entry
  1  15511             apic_send_ipi:return
...

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

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

CODE:

#!/usr/sbin/dtrace -s
#pragma D option flowindent

fbt:::
/execname == "dtrace"/
{
}

И результат:

CODE:

dtrace: script './try5.d' matched 32659 probes
CPU FUNCTION
  1  -> xc_sync
  1    -> xc_do_call
  1      -> mutex_vector_enter
  1        -> lock_set_spl
  1          -> splx
  1            -> apic_setspl
  1            <- apic_setspl
  1          <- splx
  1        <- lock_set_spl
  1      <- mutex_vector_enter
  1      -> xc_common
  1        -> apic_send_ipi
  1        <- apic_send_ipi
...

Предикаты в DTrace

nospam@example.com (Gleb Reys) — Fri, 10 Dec 2004 19:52:52 +0300

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

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

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

syscall:::
/probefunc != "write"/
{
printf("probefunc: %s, pid: %d, execname: %s\n", probefunc, pid, execname);
}

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

CODE:

probefunc: ioctl, pid: 28603, execname: dtrace
probefunc: ioctl, pid: 28603, execname: dtrace
probefunc: ioctl, pid: 28603, execname: dtrace
probefunc: ioctl, pid: 28603, execname: dtrace
probefunc: ioctl, pid: 28603, execname: dtrace
probefunc: sysconfig, pid: 28603, execname: dtrace
probefunc: sysconfig, pid: 28603, execname: dtrace
probefunc: sysconfig, pid: 28603, execname: dtrace
probefunc: sysconfig, pid: 28603, execname: dtrace
probefunc: sigaction, pid: 28603, execname: dtrace
probefunc: sigaction, pid: 28603, execname: dtrace
probefunc: sigaction, pid: 28603, execname: dtrace
probefunc: sigaction, pid: 28603, execname: dtrace
...

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

CODE:

/probefunc != "write" && execname != "dtrace"/

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

CODE:

probefunc: pollsys, pid: 28411, execname: rxvt
probefunc: ioctl, pid: 28411, execname: rxvt
probefunc: ioctl, pid: 28411, execname: rxvt
probefunc: pollsys, pid: 28411, execname: rxvt
probefunc: pollsys, pid: 28406, execname: rxvt
probefunc: ioctl, pid: 28406, execname: rxvt
probefunc: ioctl, pid: 28406, execname: rxvt
probefunc: pollsys, pid: 28406, execname: rxvt
probefunc: lwp_cond_wait, pid: 27870, execname: java_vm
probefunc: lwp_cond_signal, pid: 27870, execname: java_vm
probefunc: lwp_cond_signal, pid: 27870, execname: java_vm
probefunc: lwp_cond_wait, pid: 27870, execname: java_vm
...

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

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

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

CODE:

#!/usr/sbin/dtrace -s
#pragma D option quiet

syscall::write:return
/ self->processed == 0/
{
printf("tid: %d, pid: %d, execname: %s\n", tid, pid, execname);
self->processed = 1;
}

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

CODE:

tid: 1, pid: 21583, execname: soffice.bin
tid: 4, pid: 21750, execname: thunderbird-bin
tid: 4, pid: 27406, execname: mozilla-bin
tid: 1, pid: 27406, execname: mozilla-bin
tid: 1, pid: 21450, execname: icewm
tid: 4, pid: 21583, execname: soffice.bin
tid: 1, pid: 21750, execname: thunderbird-bin
tid: 1, pid: 28636, execname: dtrace

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