Компания Oracle объявила (https://blogs.oracle.com/linux/entry/new_beta_release_of_dtr... о начале тестирования реализации системы динамической отладки DTrace (http://ru.wikipedia.org/wiki/DTrace) для платформы Linux. Патчи с реализацией поддержки DTrace пока доступны только для ядра Unbreakable Enterprise Kernel 2 (https://www.opennet.ru/opennews/art.shtml?num=29214) (2.6.39), поставляемого в составе дистрибутива Oracle Linux (http://linux.oracle.com/).
В тестировании могут принять участие пользователи сети Unbreakable Linux Network, которым следует загрузить пакеты из репозитория ol6_x86_64_Dtrace_BETA.
Из возможностей DTrace в версии для Linux пока доступно лишь несколько базовых провайдеров (https://wikis.oracle.com/display/DTrace/Documentation). В частности, реализован dtrace-провайдер SDT (https://wikis.oracle.com/display/DTrace/sdt+Provider) (Statically Defined Tracing), позволяющий выполнять статическую трассировку приложений, используя серию контрольных вызовов (probes) ...URL: https://blogs.oracle.com/linux/entry/new_beta_release_of_dtrace
Новость: https://www.opennet.ru/opennews/art.shtml?num=33169
В чем отличие и преимущества перед strace? Или я что-то не понимаю? :)
Принципиально другая вещь.
в назначении
Примерно такая же, как анализ крови и мочи против ДНК и Рентгена.
Не надо, у нас есть SystemTap
То есть, в сухом остатке мы имеем:
- два недопиленных порта DTrace, и каждый под несовместимой с GPLv2 лицензией, а значит, оба не имеют даже теоретической перспективы быть включенными в ядро;
- SystemTap, который медленно запускается, умеет ронять систему ( http://dtrace.org/blogs/brendan/2011/10/15/using-systemtap/ ), и точно также не включен в ядро.Линукс такой линукс, и годы допиливания со стороны крупных корпораций, а также миллиарды вложенных ими долларов ничего не меняют.
я думаю, что если в FreeBSD без миллардов это сделали в период freeBSD 8-9, то и в Линукс смогут - там ведь тоже еще (вроде) обычные программисты работают. Или уже только организации с деньгами код вливают? В MacOS вот хорошо идет - 2 года назад FreeBSD занимала второе место по количеству probes (после Солярки), а сейчас - третье. Но софта с DTRACE поддержкой уже немало - и PHP 5.4 и PgSQL и MySQL и Apache.
>то и в Линукс смогут - там ведь тоже еще (вроде) обычные программисты работаютВот именно что "вроде". Вы, например, про Ульриха Дреппера что-нибудь слышали?
Кроме того, там вопрос ведь не в деньгах, а в синдроме NIH и д'Артаньяна.
> Вот именно что "вроде". Вы, например, про Ульриха Дреппера что-нибудь слышали?А он к линуксу каким боком? Или школьники настолько обмельчали что даже не знают что такое линукс? :)
Он?... Да так, майнтайнер одной мелкой библиотечки, которая в паре незначительных дистрибутивов линукса используется.
использовать systemtap на нагруженном production было бы здорово, но пока и текущие возможности довольно хороши.В конце-концов, gdb тоже работает нестабильно, watchpoint или частое attach bt detach могут вызывать падения исследуемого процесса или его заморозку.
>То есть, в сухом остатке мы имеем:отличный трассировщик с правильной лицензией http://lttng.org/
хорошая табличка.
если отбросить местный флуд и посмотреть на функциональность:
http://lttng.org/comparison-systemtap-and-dtrace
number of available symbolic probe points in the kernel
systemtap - millions (statements, markers)
dtrace - thousands (functions, markers)
> systemtap - millions (statements, markers)
> dtrace - thousands (functions, markers)Да, только systemtap роняет систему, а dtrace на соляре давно уже используется на боевых серверах.
> Да, только systemtap роняет систему, а dtrace на соляре давно уже используется
> на боевых серверах.Ага, особенно прикольно вот это:
> probe execution optimized native code optimized native code interpreted bytecode
Ну да, интерпретируемый байткод зонда в горяченьком месте - хороший подарок боевому серверу ;]
Не такой уж неприятный этот подарок - побудет он немного в горяченьком месте, потом его выключат, и overhead'а не будет вообще. Конечно, эксперимент абсолютно чистым не назовешь, однако, чистых экспериментов при такой методике вообще не бывает ни с какими профайлерами.
используется - это громко сказано.
даже у самых ярых фанов на проде есть максимум с десяток "рабочих" скриптов уровня "тоже самое, что и htop/iotop/sar/.., но только в профиль".
а такого уровня скрипты и в линухе есть, и не роняют (и не могли ронять), и всё равно не нужны - аналоги в виде программ давно есть и не через Ж работают, и вообще без оверхеда априори.
и уж тем более никто из них не будет на боевом сервере/кластере выяснять что же там с дровами рэйда из вашего надуманного (я бы сказал навеянного) примера выше.
при чем по 2-м причинам:
1. на боевом сервере не будут стоять глючные дрова рэйда по определению (собстно как они туда собственно попадут? или криворукий админ уже предполагается? :D)
2. если дело в железе - железо меняется в наикратчайшие сроки. и уж точно без разбора полётов на боевом сервере.
> 1. на боевом сервере не будут стоять глючные дрова рэйда по определению
> (собстно как они туда собственно попадут? или криворукий админ уже предполагается?Ну вот был драйвер, работал-работал, а потом взял и начал вести себя неадекватно. То ли Сатурн в созвездие Стрельца вошел, то ли нагрузка на RAID-массив стала удовлетворять какому-то особенно неудачному для данного драйвера паттерну.
> 2. если дело в железе - железо меняется в наикратчайшие сроки. и
> уж точно без разбора полётов на боевом сервере.Это хорошо, когда точно знаешь, что проблема именно в железе, а не в чем-либо еще. А это никто за вас выяснять не будет. Вот тут уже все средства будут хороши.
>Ну вот был драйвер, работал-работал, а потом взял и начал вести себя неадекватно.драйвер не железный.
не ломается.
он либо работает сразу, либо не_работает. тоже сразу.
из этих 2-х "либо" и складывается хороший админ.>Это хорошо, когда точно знаешь, что проблема именно в железе, а не в чем-либо еще.
так на то он и админ.
либо железо, либо софт - что значит либо сломалось, либо ты сам сломал.
> драйвер не железный.
> не ломается.
> он либо работает сразу, либо не_работает. тоже сразу.Мой, хоть и далеко не 10-летний опыт работы с Solaris свидетельствует о том же. А вот с другими ОС все не так безоблачно.
> так на то он и админ.
> либо железо, либо софт - что значит либо сломалось, либо ты сам
> сломал.В статическом мире - действительно, все просто - либо работает, либо нет. В реальном все несколько сложнее.
>Мой, хоть и далеко не 10-летний опыт работы с Solaris свидетельствует о том же. А вот с другими ОС все не так безоблачно.тоже самое и мой, но со всеми *nix.
а мы про них и говорим.баги бывают, но они выявляются через dmesg/логи/sar/... (которые админ должен читать не зависимо от наличия dtrace :D) и как правило на раннем этапе.
>В статическом мире - действительно, все просто - либо работает, либо нет. В реальном все несколько сложнее.
не в статическом, а в перманентно-постоянном.
вы следите за тем, какие именно обновления ставятся?
я - да.
> Да, только systemtap роняет систему, а dtrace на соляре давно уже используется на боевых серверах.... где он благополучно роняет систему, а в остальное время дико ее тормозит.
Можно себе представить, что это за "боевые" серверы.
>если отбросить местный флуд и посмотреть на функциональность:
>systemtap
>dtraceвообще-то я имел ввиду совсем не их - зачем они нужны при наличии lttng ;) при наличии аппаратных возможностей в процессоре (например CoreSight у ARM) - отличный инструмент для исследования реалтайм процессов - скорость, минимальный оверхед, инструменты для последующей визуализации полученных данных.
да тоже ничего.
я вот oprofile'ом иногда пользуюсь. http://oprofile.sourceforge.net/
да, вот это не распарсил
>Система SystemTap не принята в состав основного ядра Linux.ванильное (!!!) ядро собранное с опциями DEBUG_FS, RELAY, KPROBES и установленным dev-util/systemtap-1.7
результат:
# uname -a
Linux victor-laptop 3.2.6-gentoo #2 SMP PREEMPT Fri Feb 24 10:56:42 MSK 2012 x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
# stap iotop.stp
Process KB Read KB Written
gconfd-2 3 86
chrome 19 6
X 23 0
...что я делаю не так?
Да, похоже, здесь я был неправ. Когда последний раз пробовал SystemTap (а это было далеко не вчера), пришлось отказаться от ванильного ядра, но, видимо, по отличной от неработающего SystemTap причине. Виноват.
А чё вообще шухер подняли??? Больше отладчиков хороших и разных!!!
> А чё вообще шухер подняли??? Больше отладчиков хороших и разных!!!да, отладчик очень помогает в Имитации Бурной Деятельности. видишь человека за отладчиком — и сразу ясно: с огромной вероятностью занимается ерундой.
Это маркетинговая новость, граждане. Рекомендуемая к прочтению статья http://dtrace.org/blogs/ahl/2011/10/05/dtrace-for-linux-2/
> Это маркетинговая новость, граждане. Рекомендуемая к прочтению статья http://dtrace.org/blogs/ahl/2011/10/05/dtrace-for-linux-2/Это статья была написана почти полгода назад, когда кроме обещаний Oracle ничего не было известно. Сейчас появились готовые пакеты для тестирования. Т.е. Oracle сдержал обещания и все опасения ahl не опарвдались.
>> Это маркетинговая новость, граждане. Рекомендуемая к прочтению статья http://dtrace.org/blogs/ahl/2011/10/05/dtrace-for-linux-2/
> Это статья была написана почти полгода назад, когда кроме обещаний Oracle ничего
> не было известно. Сейчас появились готовые пакеты для тестирования. Т.е. Oracle
> сдержал обещания и все опасения ahl не опарвдались.добавил не ту ссылку. Моя вина:(
FIX: http://dtrace.org/blogs/ahl/2012/02/23/dtrace-oel-update/