Категории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, November 26. 2004
Пробы в DTrace - ... Posted by Gleb Reys
in DTrace at
17:39
Comments (0) Trackbacks (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, November 25. 2004
Пробы в DTrace Posted by Gleb Reys
in DTrace at
16:10
Comments (0) Trackbacks (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, November 24. 2004
One more useful DTrace command line Posted by Gleb Reys
in DTrace at
15:49
Comments (0) Trackbacks (0) Defined tags for this entry: dtrace
One more useful DTrace command line
One more variation of using DTrace allows to track which system calls are made from a certain process. Or do the same for lots of processes, if you use execname and not PIDs...
Such a command line will show you all system calls made by Xorg in the last 5 seconds: 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: some time later I'll hopefully write more about what DTrace and D language are Monday, November 22. 2004DTrace: as easy as it gets
I'm slowly getting used to seeing and using DTrace in my everydays work...
For example, here's a start of the most basic analysis. The system is constantly busy with something, and our task is to find what's responsible for this. How? One of the possible solutions is to simply watch the system for a certain period of time (5 seconds in our case) to see what process makes most system calles... And it's clearly seen now that the most active consumer of system calls is Java VM which happens to run a very complex graphics applet at this very moment. As for rxvt terminals, we're seeing so many calls simply because we're building our list based on the command name and not PID, so in the table we really see the cumulative number of system calls made by roughly 40 terminals I've got running on my box, and not a single session as one might think. Had I done the PID-based list, all the 40+ rxvt processes would have shown separately. Here it goes: dtrace -n syscall:::entry'{@[execname] = count()} tick-5sec {printa(@); clear(@);}' And this is the result of such a command line. Every 5 seconds you'll see an output similar to this: 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 |





