КатегорииLinksUnix Tutorial
Personal Development Ruslan Valiev Solaris Performance Team Damien Farnham Fintan Ryan Nicky Veitch Niall Mullen Sean McGrath DTrace Bryan Cantrill Brendan Gregg ZFS Tim Foster General Ben Rockwood Learning Solaris 10 Privacy policy |
Tuesday, 7 December. 2004
Встроенные ... Добавил Gleb Reys
в категории DTrace в
17:51
Комментарии (0) Обратные ссылки (0) Defined tags for this entry: dtrace
Встроенные переменные DTrace
В DTrace есть довольно много очень полезных встроенных переменных.
Полный их список приведён здесь, а пока я расскажу лишь про несколько из них. В этой заметке мы рассмотрим простейшие переменные, а в последующих записях постепенно научимся использовать и более сложные. Позволю себе разбить переменные на несколько групп. Помимо имени переменной, я также приведу её тип. Итак: 1) Имена файлов и каталогов string cwd - имя текущего каталога того процесса, которому принадлежит текущий thread string execname - символьное имя, которое было передано функции exec(2) для исполнения текущего процесса. 2) Процессы id_t tid - номер текущего thread'а. Для thread'ов пользовательских процессов, это значение будет равно результату вызова pthread_self(3C). pid_t pid - идентификатор процесса (PID) текущего процесса pid_t ppid - parent PID текущего процесса uid_t uid - пользовательский ID текущего процесса gid_t gid - идентификатор группы (group ID) текущего процесса 3) Пробы uint_t id - ID номер текущей пробы. Это тот самый номерок, что видно в таблице доступны проб при вызове команды dtrace -l string probefunc - имя функции согласно описанию текущей пробы string probemod - имя модуля согласно описанию текущей пробы string probename - имя пробы согласно описанию текущей пробы string probeprov - имя провайдера согласно описанию текущей пробы 4) Прочее int errno - код ошибки, возвращённый последним системным вызовом, выполненным текущим thread'ом uint64_t timestamp - текущее время счётчика наносекунд. Данный счётчик не привязан к текущему времени в системе, и потому должен использоваться только для относительных вычислений. Использовать эти переменные можно как угодно - один из простейших вариантов применения приведён ниже. Я привожу полный текст скрипта, поэтому если вы его сохраните под именем script.d и сделаете этому файлу chmod u+x ./script.d, то его можно будет запускать прямо из командной строки. Пока не обращайте внимания на строку с pragma D option, про несколько полезных опций DTrace я расскажу через несколько дней. ВНИМАНИЕ: в целях компактного размещения кода, я разбил длинные строки с printf на несколько строк. Если вы хотите запустить данный скрипт, вам следует склеить такие строки. CODE: #!/usr/sbin/dtrace -s #pragma D option quiet :::write:entry { printf("\nProcess info:\ntid=%d, pid=%d, ppid=%d, uid=%d, gid=%d\n", tid, pid, ppid, uid, gid); printf("CWD=%s, execname=%s\n", cwd, execname); printf("Probe info:\nid=%d, probeprov=%s, probemod=%s, probefunc=%s, probename=%s\n", id, probeprov, probemod, probefunc, probename); } Запущенный на вашей машине, данный скрипт выдаст вам примерно следующее (будет ОЧЕНЬ много строк, так как мы ловим, согласно шаблону, все обращения к вызову write): CODE: Process info:
tid=1, pid=22157, ppid=21995, uid=123, gid=10 CWD=/export/greys/./dtrace, execname=dtrace Probe info: id=6295, probeprov=fbt, probemod=genunix, probefunc=write, probename=entry Process info: tid=1, pid=21993, ppid=21450, uid=123, gid=10 CWD=/home/gr128638, execname=rxvt Probe info: id=12, probeprov=syscall, probemod=, probefunc=write, probename=entry Monday, 6 December. 2004
Официальное ... Добавил Gleb Reys
в категории DTrace в
20:06
Комментарии (2) Обратные ссылки (0) Select language: English Defined tags for this entry: dtrace
Официальное руководство по DTrace
Это уже далеко не новость, так как вы все, скорее всего, уже знаете эту ссылку, но тем не менее:
Solaris Dynamic Tracing Guide А вспомнил про эту ссылку я потому, что хотел рассказать о примерах, которые приведены в этом руководстве. Их довольно много, они простые и в то же время очень полезные. Так что на практике могут запросто пригодиться. Все эти примеры находятся в каталоге /usr/demo/dtrace, и открыв в вашем браузере файл /usr/demo/dtrace/index.html, вы сможете увидеть все примеры в таблице, разбирающей их по главам руководства по DTrace. Wednesday, 1 December. 2004
DTrace и настройка ... Добавил Gleb Reys
в категории DTrace в
16:48
Комментарии (3) Обратная ссылка (1) Defined tags for this entry: dtrace
DTrace и настройка привилегий
Одним из нововведений Solaris 10 являются привилегии - механизм, позволяющий легко ограничивать возможности пользователей или процессов в системе.
man privileges содержит список всех доступных привилегий, я же здесь пока затрону лишь те, которые относятся к DTrace. Смысл всего этого вот в чём - DTrace это довольно опасное оружие в умелых руках, и потому простые пользователи Solaris не должны иметь к нему доступ так же, как и они не должны иметь доступа к файлам других пользователей. Поэтому, попытка выполнить команду типа dtrace -l из-под обычного пользователя приведёт к такой вот ошибке: dtrace: failed to initialize dtrace: DTrace requires additional privileges По умолчанию, только root может пользоваться DTrace. Чтобы позволить другим пользователям тоже как-то использовать DTrace, существуют три привилегии, которые им может выдавать администратор: dtrace_proc - даёт пользователю лишь доступ к провайдеру pid. Естественно, доступна будет лишь информация о процессах, принадлежащих этому пользователю. dtrace_user - даёт пользователю доступ к провайдерам profile и syscall, опять же в рамках процессов, принадлежащих этому пользователю. dtrace_kernel - даёт доступ ко всем провайдерам, кроме pid, если он не позволен привилегией dtrace_proc. Губительные для ядра (kernel-destructive) функции недоступны. Вот эти три функции считаются kernel-destructive: breakpoint() - выбросит систему в отладчик ядра. На Sparc-системах вы окажетесь в ok приглашении OBP, а на x86 системах можете оказаться в kadb panic() - вызовет панику ядра (смешно переводить слова, которые никогда по-русски не говорятся) в целях получения крэш-дампа chill() - глобальный sleep, если хотите. Заставляет DTrace ждать указанное количество наносекунд. Естественно, это отразится на всей системе. Так вот, обычному пользователю, какие бы вы ему привилегии не давали, доступа к этим трём функциям нет. Вкратце, привилегии выдаются так: Нужно добавить в файлик /etc/user_attr строку с указанием привилегий для конкретного пользователя. Скажем, если имя пользователя - greys, то вот эта строчка даст ему возможность творить с помощью DTrace всё, что только можно позволить с помощью привилегий простому пользователю: greys::::defaultpriv=basic,dtrace_proc,dtrace_user,dtrace_kernel ну, или если не хочется пользователю надолго давать такие привилегии, можно осчастливить лишь процесс его командной оболочки командой: ppriv -s A+dtrace_user PID В этом случае пользователь сможет провести необходимые ему эксперименты, но по выходу из оболочки он эти волшебные свойства утратит до следующего вашего приступа душевной доброты. Friday, 26 November. 2004
Пробы в DTrace - ... Добавил Gleb Reys
в категории DTrace в
17:39
Комментарии (0) Обратные ссылки (0) Defined tags for this entry: dtrace
Пробы в DTrace - продолжение
Процесс написания скрипта на языке DTrace - D - очень прост. После того, как вы выяснили, за чем вы хотели бы проследить в системе, нужно просто указать эти критерии в виде простейших фильтров проб, и подсказать, что делать DTrace, когда в процессе отладки попадается что-то удовлетворяющее критериям этих фильтров.
Начнём с простейшего: в DTrace есть две пробы, которые очень легко запомнить. В то же время, они бывают очень полезными при написании сложных d-скриптов. Называются эти пробы BEGIN и END, и исполняются они, как видно из названия, перед началом отладки и по её завершению. Как видно из примера ниже, синтаксис у языка D прост, понятен и многим знаком по другим языкам программирования: CODE: BEGIN { printf("Hello, world"); exit(0); } END { printf("The End"); } Если сохранить этот текст в файл, то позже его можно скормить команде dtrace в помощью ключика -s: dtrace -s ./try.d А результатом выполнения такой команды будет следующее: CODE: dtrace: script './try.d' matched 2 probes CPU ID FUNCTION:NAME 0 1 :BEGIN Hello, world 0 2 :END The End Первое поле - CPU - указывает процессор, на котором сработала та или иная проба DTrace. В данном случае мы пытались поймать встроенные пробы BEGIN и END, и потому они поймались на том же процессоре, который исполнял команду dtrace - 0. Поле ID - это числовой код проб BEGIN и END, и если вернуться к предыдущей записи в блоге - Пробы в DTrace, то в таблице всех проб, доступных для использования, первыми стоят именно пробы BEGIN и END, под номерами 1 и 2. Ну и последнее поле выводит имя той пробы, которая сработала. И если в теле процедуры обработки пробы есть какие-то операции, они будут выполнены. В нашем случае там стоят printf'ы, которые и выводят сообщения Hello, world и The End. С такой же лёгкостью можно ловить какие угодно пробы! Например, следующий пример будет ловить всё новые случаи выполнения системного вызова write и указывать, какой процесс его запросил - pid и execname это встроенные переменные DTrace, я позже расскажу о них подробнее. Итак, наш новый скрипт try.d, я для удобства не стал убирать из него BEGIN и END, чтобы была возможность сравнить и убедиться, что добавление любой другой пробы ничуть не сложнее. Как я уже говорил, можно отследить моменты входа и выхода из системного вызова - я в этом примере слежу за точками входа (entry): CODE: BEGIN { printf("Hello, world"); } syscall::write:entry { printf("pid: %d, execname: %s", pid, execname); } END { printf("This is the end."); } Результатом будет бесконечная таблица, похожая на приведённую ниже. Вам следует нажать Ctrl+C чтобы прервать трассировку. CODE: dtrace: script './try.d' matched 3 probes CPU ID FUNCTION:NAME 1 1 :BEGIN Hello, world 0 12 write:entry pid: 21053, execname: dtrace 0 12 write:entry pid: 20598, execname: rxvt 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20475, execname: icewm 0 12 write:entry pid: 20475, execname: icewm 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20475, execname: icewm 0 12 write:entry pid: 20475, execname: icewm 0 12 write:entry pid: 20595, execname: mozilla-bin 0 12 write:entry pid: 20595, execname: mozilla-bin 1 2 :END This is the end. Видите, как просто и понятно получается отлаживать работающую систему? Сразу становится видно, что за эти несколько секунд, что я ждал, к системному вызову write прибегли: собственно dtrace (потому что вывод данных производил), rxvt (терминал), mozilla-bin (браузер, естессно) и icewm - мой оконный менеджер. С таким же успехом можно вместо syscall::write:entry указать любую другую маску для проб DTrace. Вот лишь несколько вариантов: syscall::write:return - отслеживать лишь выходы из вызовов write syscall::write: - отслеживать и входы, и выходы из вызовов write syscall::: - отслеживать входы и выходы всех системных вызовов Thursday, 25 November. 2004
Пробы в DTrace Добавил Gleb Reys
в категории DTrace в
16:10
Комментарии (0) Обратные ссылки (2) Defined tags for this entry: dtrace
Пробы в DTrace
Раз уж начал потихоньку рассказывать про DTrace, попробую самого простого не упускать тоже.
DTrace позволяет отлаживать любые процессы в Solaris 10, посредством проб. В ядро системы встроены модули, которые называются провайдеры - и каждый из них позволяет отлаживать какую-то область операционной системы. Скажем, есть провайдер syscall, который позволяет отслеживать системные вызовы. Есть провайдеры sysinfo или vminfo, о функциональности которых можно догадаться из названия... И так далее. Так вот, каждый провайдер предоставляет DTrace список проб - тех точек перехвата, где провайдер может отдать DTrace какую-то статистику. Скажем, для syscall пробами будут все системные вызовы, которые можно отслеживать с его помощью - read, write, wait, exec - вернее даже, те точки их выполнения, которые данный провайдер позволить отследить. Обычно это момент входа в системный вызов (entry) и возврата после его выполнения (return). Чтобы просмотреть список всех провайдеров и всех проб, доступных DTrace, следует использовать такую команду: dtrace -l CODE: ID PROVIDER MODULE FUNCTION NAME 1 dtrace BEGIN 2 dtrace END 3 dtrace ERROR 4 syscall nosys entry 5 syscall nosys return 6 syscall rexit entry 7 syscall rexit return 8 syscall forkall entry 9 syscall forkall return 10 syscall read entry 11 syscall read return 12 syscall write entry 13 syscall write return 14 syscall open entry 15 syscall open return 16 syscall close entry 17 syscall close return 18 syscall wait entry 19 syscall wait return 20 syscall creat entry 21 syscall creat return 22 syscall link entry 23 syscall link return 24 syscall unlink entry 25 syscall unlink return 26 syscall exec entry 27 syscall exec return 28 syscall chdir entry ... Весь список здесь приводить не стану - он просто огромен - у меня он занимает 36654 строки. Есть ещё один очень полезный вариант команды, который позволяет найти конкретный системный вызов с целью выяснения, каким провайдером он предоставляется: dtrace -l -f read CODE: bash-2.05b# dtrace -l -f read ID PROVIDER MODULE FUNCTION NAME 10 syscall read entry 11 syscall read return 3268 sysinfo genunix read readch 3272 sysinfo genunix read sysread 7043 fbt genunix read entry 7044 fbt genunix read return Из результата выполнения команды сразу же видно, что несколько провайдеров предоставляют возможность перехватывать их функции с именем read. Причём, если бы мы сделали dtrace -l | grep read, то было бы гораздо больше результатов, потому что есть очень много функций, в названии которых включается это слово. |




