DTrace

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

Начнём с простейшего: в DTrace есть две пробы, которые очень легко запомнить. В то же время, они бывают очень полезными при написании сложных d-скриптов. Называются эти пробы BEGIN и END, и исполняются они, как видно из названия, перед началом отладки и по её завершению.

Как видно из примера ниже, синтаксис у языка D прост, понятен и многим знаком по другим языкам программирования:



Если сохранить этот текст в файл, то позже его можно скормить команде dtrace в помощью ключика -s:

dtrace -s ./try.d

А результатом выполнения такой команды будет следующее:


Первое поле - 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):



Результатом будет бесконечная таблица, похожая на приведённую ниже. Вам следует нажать Ctrl+C чтобы прервать трассировку.



Видите, как просто и понятно получается отлаживать работающую систему? Сразу становится видно, что за эти несколько секунд, что я ждал, к системному вызову write прибегли: собственно dtrace (потому что вывод данных производил), rxvt (терминал), mozilla-bin (браузер, естессно) и icewm - мой оконный менеджер.

С таким же успехом можно вместо syscall::write:entry указать любую другую маску для проб DTrace.
Вот лишь несколько вариантов:

syscall::write:return - отслеживать лишь выходы из вызовов write
syscall::write: - отслеживать и входы, и выходы из вызовов write
syscall::: - отслеживать входы и выходы всех системных вызовов

Раз уж начал потихоньку рассказывать про DTrace, попробую самого простого не упускать тоже.

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

Скажем, есть провайдер syscall, который позволяет отслеживать системные вызовы. Есть провайдеры sysinfo или vminfo, о функциональности которых можно догадаться из названия... И так далее.

Так вот, каждый провайдер предоставляет DTrace список проб - тех точек перехвата, где провайдер может отдать DTrace какую-то статистику. Скажем, для syscall пробами будут все системные вызовы, которые можно отслеживать с его помощью - read, write, wait, exec - вернее даже, те точки их выполнения, которые данный провайдер позволить отследить. Обычно это момент входа в системный вызов (entry) и возврата после его выполнения (return).

Чтобы просмотреть список всех провайдеров и всех проб, доступных DTrace, следует использовать такую команду:

dtrace -l



Весь список здесь приводить не стану - он просто огромен - у меня он занимает 36654 строки.

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

dtrace -l -f read



Из результата выполнения команды сразу же видно, что несколько провайдеров предоставляют возможность перехватывать их функции с именем read. Причём, если бы мы сделали dtrace -l | grep read, то было бы гораздо больше результатов, потому что есть очень много функций, в названии которых включается это слово.

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(@);}'



pS: some time later I'll hopefully write more about what DTrace and D language are

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: