Подписаться на этот блог    
Категории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 Архивы |
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, то было бы гораздо больше результатов, потому что есть очень много функций, в названии которых включается это слово. Wednesday, 24 November. 2004
Ещё один из любимых ... Добавил Gleb Reys
в категории DTrace в
15:49
Комментарии (0) Обратные ссылки (0) Select language: English Defined tags for this entry: dtrace
Ещё один из любимых приёмов вызова DTrace
Данный вариант вызова команды позволяет отследить, какие именно системные вызовы выполняются определённым процессом. Или целой их кучей, если делать выборку по символьному имени, а не по PIDам...
Такакя вот строчка покажет статистику системных вызовов X-сервера Xorg за каждые 5 секунд: dtrace -n 'syscall:::entry /execname == "Xorg"/ {@[probefunc] = count(); } tick-5sec {printa(@); clear(@);}' CODE: dtrace: description 'syscall:::entry ' matched 227 probes CPU ID FUNCTION:NAME 0 36588 :tick-5sec writev 20 lwp_sigmask 38 setcontext 38 setitimer 75 read 422 pollsys 426 pS: как-нибудь чуть попозже соберусь и всё-таки напишу подробнее, что такое DTrace и язык D. Monday, 22 November. 2004
Проще простого Добавил Gleb Reys
в категории DTrace в
19:35
Комментарии (2) Обратные ссылки (0) Select language: English
Проще простого
Потихоньку привыкаю использовать DTrace в повседневной работе...
Например, вот начало элементарного анализа. Система чем-то постоянно занята, и нужно попытаться найти, кто же виноват. Как? Вот одно из возможных решений - просто посмотреть, кто за конкретный промежуток времени (в нашем случае - 5 секунд) делает больше всего системных вызовов... И сразу становится понятно, что это всё Java VM, которая как раз сейчас работает со сложным графическим апплетом. Ну а терминалы rxvt так много насчитали потому, что мы строим список по названию команд, а у меня на машине открыто штук 40 терминалов, и все они, естественно, rxvt - т.е. если бы я по PID делал сортировку, они все были бы отдельно. Итак, команда: dtrace -n syscall:::entry'{@[execname] = count()} tick-5sec {printa(@); clear(@);}' А результат её - каждые пять секунд мы будем видить что-нибудь вроде этого: CODE: dtrace: description 'syscall:::entry' matched 227 probes
CPU ID FUNCTION:NAME 1 36588 :tick-5sec svc.configd 1 expect 3 telnet 4 svc.startd 6 sendmail 10 thunderbird-bin 10 htt_server 10 nscd 13 mozilla-bin 19 soffice.bin 77 xautolock 106 dtrace 173 icewm 225 Xorg 874 rxvt 2008 java_vm 2651 |